PerimeterX / HUMAN ACTIVE
Four request-based web solvers + a native-app mobile solver. Native Go, no browser.
Overview
VexSolver ships five endpoints so you use the right tool for each:
- › Web solver —
/api/solve· give a URL, get the cookie set back. - › Generator —
/generate· high-trust press-hold:1000:tokens for sensitive actions, with one-call self-clearing cart elevation. - › Payload transformer —
/px/payload+/px/decode· you send from your own IP so the token binds there. - › One-call solve —
/px/solve· same underlying flow as the transformer above, but we execute it and just hand you the cookie. - › Mobile solver —
/api/solve-mobile· the mobile-SDK header set for native apps.
Under the hood the web solvers run PerimeterX's multi-event fingerprint protocol natively in Go — PX2 (init), PX3 (canvas / audio / WebGL), PX23 / PX203 (high-security hashes), PX182 (heartbeat) — decode the XOR-encrypted OB responses, and bake the _px3, _pxhd, _pxde cookies. If a site triggers a WASM captcha, VexSolver auto-solves the proof-of-work and simulates Press & Hold.
Every call is a POST to https://api.vexsolver.com with a JSON body and your key header X-API-Key: sk_live_…. Bad key → 401; no credits → 402. You are billed 1 credit per successful mint — failed attempts are free. To check your key and credit balance without spending a credit, call GET /api/balance (same X-API-Key header) — it returns { credits, email } and 401s the same way a real solve would on a bad key.
Pasted the wrong thing? /api/solve, /generate, /px/payload, /px/decode and /px/solve all recognize a PerimeterX block-page URL (the /blocked?url=…&uuid=… link your browser lands on after a trip) and automatically recover + solve the real page underneath instead of wasting a credit trying to solve the block page itself.
Which solver do I use?
- › You have a target URL and want ready cookies, solved through your proxy —
/api/solve. - › You need a high-trust token for a sensitive W4lm4rt action (cart, checkout, sign-in) —
/generate. - › You have your own residential IPs and want the token bound to them, and don't mind driving the request yourself —
/px/payload+/px/decode. - › You want that same own-IP token but don't want to drive the multi-step flow yourself —
/px/solve. - › You are automating a native mobile app (W4lm4rt app, T3xtN0w app) —
/api/solve-mobile.
1 — Web solver (/api/solve)
The workhorse. Give it a URL and a proxy; it runs the full collector flow server-side and returns the browsing-grade cookie set. Async: submit gets a taskId, then poll (or pass a webhook callback).
Tested sites:
- ›
w4lm4rt.com·w4lm4rt.ca·identity.w4lm4rt.com - ›
wayfa1r.com·z1ll0w.com·5ky5c4nn3r(all TLDs) - ›
pr1z3p1ck5.com·t3xtn0w.com
# 1. Submit
curl -X POST https://api.vexsolver.com/api/solve \
-H "X-API-Key: sk_live_..." \
-H "Content-Type: application/json" \
-d '{
"url": "https://www.w4lm4rt.com/",
"proxy": "http://user:pass@your-proxy:8080"
}'
# → { "taskId": "abc123xyz" }
# 2. Poll (retry every 1-2s until status is "ready" or "error" — never poll on "processing")
curl -G "https://api.vexsolver.com/api/getTaskResult" \
-H "X-API-Key: sk_live_..." \
--data-urlencode "taskId=abc123xyz"
# → { "status": "processing", "solution": null } (keep polling)
# → { "status": "ready", "solution": { ...below... } } (done)
# → { "status": "error", "error": "..." } (stop — will not become ready)Pass "app_id" to skip AppId auto-detection on a custom or first-party deployment. Pass "fresh": true to bypass the 5-min cache, and "user_agent" to pin the exact UA your TLS client replays with.
solution, once status is "ready" — not what /api/solve itself returns (that's just the taskId above):
{
"success": true,
"vendor": "perimeterx",
"user_agent": "Mozilla/5.0 ... Chrome/147.0.0.0 Safari/537.36",
"cookies": "_px3=...; _pxde=...; _pxhd=...",
"cookie_map": { "_px3": "...:1000:...", "_pxde": "...", "_pxhd": "..." },
"elapsed_ms": 596
}auto_elevate mechanism documented under /generate below is also available directly on /api/solve for w4lm4rt.ca: add "auto_elevate": true (and optionally "max_attempts": 5) to your submit body and poll as usual. The returned solution gains cleared_verified / verify_status / attempts_used / proxy_session / exit_ip — cleared_verified: true means we replayed the real cart mutation and PerimeterX genuinely accepted it, not just that a cookie minted. Pin your own real replay to the returned proxy_session/exit_ip— the minted token is exit-IP-bound, a different egress invalidates it. Already have a captured 412? Pass solve_block: true, block_html (the raw 412 body), and verify: trueinstead — same self-verify guarantee, against a block you supply rather than one we provoke.2 — Generator (/generate)
A native press-hold generator that mints the high-trust tier — the :1000: cleared-user (cs=cu) _px3 that sensitive actions require. Pick a deployment instead of a raw URL; the response is direct (no polling).
Deployments:
- ›
w4lm4rt-com— www.w4lm4rt.com (PXu6b0qd2S) - ›
w4lm4rt-ca— www.w4lm4rt.ca (PXnp9B16Cq) - ›
identity— identity.w4lm4rt.com
curl -X POST https://api.vexsolver.com/generate \
-H "X-API-Key: sk_live_..." \
-H "Content-Type: application/json" \
-d '{
"deployment": "w4lm4rt-com",
"target_url": "https://www.w4lm4rt.com/",
"proxy": "http://user:pass@your-proxy:8080"
}'
# → {
# "minted": true,
# "px3": "...:1000:...",
# "cookies": "_px3=...; _pxde=...; _pxvid=...; cc=...",
# "cart_cleared": true, "elevated": true, "trust": "1000", "ms": 12000
# }cookies is a ready-to-send Cookie: header string, not an object — split on "; " yourself if you need individual values. ms is typically 10-15 seconds when minting cleanly, and up to 30-50 seconds when the fast path needs the press-hold escalation described below.
deployment-only call can come back 200 on a normal page load and still get 412'd the moment you actually try to add to cart. Pass auto_elevate: true and we do the whole thing for you: mint a session, deliberately provoke the real add-to-cart 412 ourselves, elevate that exact fresh blockwith a real press-hold, and self-verify against the real cart endpoint before returning — you never have to capture or forward a 412 yourself.curl -X POST https://api.vexsolver.com/generate \
-H "X-API-Key: sk_live_..." \
-H "Content-Type: application/json" \
-d '{
"auto_elevate": true,
"target_url": "https://www.w4lm4rt.ca/cart",
"max_attempts": 8
}'
# → { "minted": true, "px3": "...:1000:...", "elevated": true, "cart_cleared": true,
# "target_verified": true, "target_status": 200, "trust": "1000", "ms": 34000 }max_attempts(default 3) bounds how many times we rotate to a fresh exit and retry the whole provoke-elevate-verify cycle if the cart gate stays blocked — each full cycle costs 20-30 seconds. This is gated on the real IP reputation of the exit each attempt lands on, same as every trust-tiered gate PerimeterX runs — it is not a 100%-every-call guarantee, but higher max_attempts meaningfully improves your odds; 8 is a solid default under normal pool load.cart_cleared and target_verified both reflect the real cart-endpoint check here, not just whether a cookie minted — if they're false, err tells you why.412 yourself (rather than having us provoke a fresh one via auto_elevate), forward the raw response body as block_html— we auto-extract app_id/uuid/vid from it and run a real press-hold elevation against that exact session.curl -X POST https://api.vexsolver.com/generate \
-H "X-API-Key: sk_live_..." \
-H "Content-Type: application/json" \
-d '{
"target_url": "https://www.w4lm4rt.com/",
"block_html": "<the raw 412 response body>",
"proxy": "http://user:pass@your-proxy:8080"
}'
# → { "minted": true, "px3": "...:1000:...", "elevated": true, "cart_cleared": true,
# "target_verified": true, "target_status": 200, "ms": 24000 }Reuse the same proxy/IPas the original request — the block is session-bound, a different exit invalidates it.app_id/uuid/vid can be passed explicitly instead of block_htmlif you've already parsed the 412 yourself.cart_cleared reflects whether the press-hold mint itself succeeded; target_verified is the stronger check — we re-fetch target_url with the fresh token and confirm it actually clears. A mint can succeed (cart_cleared: true) while target_verified is still false if the target continues to edge-block — check err in that case.3 — Payload transformer (/px/payload + /px/decode)
For when you want the token bound to your own IP. We build the exact PerimeterX collector request; you send it from your IP so PX binds the token there; then we decode PX's reply into the finished _px3. Tested on w4lm4rt.com and w4lm4rt.ca. Building is free — you are charged 1 credit only when the decode mints a real token.
# Step 1 — build the collector request (FREE)
curl -X POST https://api.vexsolver.com/px/payload \
-H "X-API-Key: sk_live_..." \
-d '{
"url": "https://www.w4lm4rt.com/",
"app_id": "PXu6b0qd2S",
"uuid": "your-session-uuid",
"vid": "your-session-vid"
}'
# → { "requests": [ { method, url, headers, body } ],
# "session": { "tag": "eW5CaD8..." } }
# Step 2 — YOU send requests[0] from your residential IP.
# PX replies: { "do": null, "ob": "..." }
# Step 3 — decode the reply into your _px3 (charged on a real mint)
curl -X POST https://api.vexsolver.com/px/decode \
-H "X-API-Key: sk_live_..." \
-d '{
"collector_response": "<the PX reply body>",
"tag": "<tag from step 1>",
"uuid": "<same uuid>",
"app_id": "PXu6b0qd2S"
}'
# → { "px3": "...:1000:...", "px3_minted": true,
# "baked_cookies": { "_px3": "...", "_pxde": "..." } }4 — One-call solve (/px/solve)
Don't want to drive the three-step exchange above yourself? /px/solve runs the exact same request-building logic /px/payload + /px/decode use, but executes every step server-side and hands you a finished cookie in one call — same response shape as /api/solve, no polling. Currently scoped to w4lm4rt-class (HC / press-hold) deployments; other appIds get a clear 400 pointing you back to the manual flow above.
curl -X POST https://api.vexsolver.com/px/solve \
-H "X-API-Key: sk_live_..." \
-H "Content-Type: application/json" \
-d '{
"url": "https://www.w4lm4rt.ca/",
"app_id": "PXnp9B16Cq"
}'
# → {
# "success": true,
# "cookies": "_px3=...; _pxde=...; _pxhd=...",
# "cookie_map": { "_px3": "...:1000:...", "..." },
# "trust": "1000",
# "target": "https://www.w4lm4rt.ca/",
# "elapsed_ms": 4385
# }Billed the same way as the manual flow — 1 credit only when a real token actually mints. Also honors the block-page URL auto-recovery described above: pass a /blocked?url=… link straight through as url and the target field in the response will show the real page we recovered and solved.
5 — Mobile solver (/api/solve-mobile)
Native Android / iOS apps that ship PerimeterX's mobile SDK (com.perimeterx.mobile_sdk, currently v3.4.7) speak a different protocol than web: one /api/v1/collector/mobile POST mints the session, then X-PX-* headers — not cookies — carry it on every outgoing request. Same async submit + poll pattern as /api/solve.
Tested apps:
- › W4lm4rt — PXu6b0qd2S (US) · PXnp9B16Cq (CA) ·
com.w4lm4rt.android - › T3xtN0w — PXK56WkC4O ·
com.3nfl1ck.android.T3xtN0w
curl -X POST https://api.vexsolver.com/api/solve-mobile \
-H "X-API-Key: sk_live_..." \
-H "Content-Type: application/json" \
-d '{
"app_id": "PXnp9B16Cq",
"app_package": "com.w4lm4rt.android",
"app_name": "W4lm4rt",
"app_version": "26.28",
"user_agent": "WMT1H/26.28 Android/14",
"proxy": "http://USER:PASS@mobile-host:PORT"
}'
# → final poll result:
{
"success": true,
"vendor": "perimeterx-mobile",
"vid": "...", "uuid": "...",
"headers": {
"X-PX-AUTHORIZATION": "3:<token>:1000:...",
"X-PX-OS": "Android",
"X-PX-OS-VERSION": "14",
"X-PX-MOBILE-SDK-VERSION": "3.4.7",
"X-PX-UUID": "...",
"X-PX-DEVICE-FP": "...",
"X-PX-DEVICE-MODEL": "SM-S911B"
}
}Attach the headers map to your app's own API requests — the token rides as X-PX-AUTHORIZATION: 3:<token>, never as a cookie. A mobile token presented as a web cookie is blocked.
- Replay through the same proxy you passed to the solve
- Replay with the same User-Agent — pin it via
user_agent, or read it back from the result - Keep the full cookie set together (
_px3 + _pxde + _pxhd) for web, or the fullX-PX-*header set for mobile
identity.w4lm4rt.com and the W4lm4rt app), Wayfa1r, Z1ll0w, 5ky5c4nn3r (all TLDs), Pr1z3P1ck5, T3xtN0w (app), crunchb4s3, 1nde3d, t1cketm4ster, 5t0ckx, 534tge3k, fub0.tv, 5p0th3r0, b3lk, we5tm4r1ne, and dozens more.Typical performance
- › Cache hit: 1-30 ms (
cached: true) - › Web replay template: 500 ms - 2 s
- › Web cold capture: 3-8 seconds
- › With WASM captcha: 10-12 seconds
- › Generator (press-hold): 5-9 seconds
- › Mobile mint: ~300 ms - 2 s (on a clean mobile IP)
added more bugs to fix it later ;}
