PerimeterX · HUMAN Security

That is PerimeterX's Advanced Blocking Response (ABR): high-security tenants block your API/XHR call with a JSON 403 instead of an HTML page, so nothing renders a press-and-hold. Solve it with the same `AntiPerimeterXTask` plus a few fields: - `blockMode`: `"xhr"` - `blockData`: the raw JSON body of the 403 you got (it carries `appId` / `uuid` / `blockScript`) - `initCookies`: your flagged session cookies, including the `_px3` that is now getting 403s - `blockUrl` / `blockMethod`: the exact request that got blocked We rebuild the challenge from `blockData`, fire `blockUrl` so PerimeterX renders the press-and-hold, hold it, and return a fresh `_px3` that clears your endpoint. Replay through the SAME proxy + User-Agent. ```json { "type": "AntiPerimeterXTask", "websiteURL": "https://site.com/account/summary", "blockMode": "xhr", "blockData": "{\"appId\":\"PX...\",\"uuid\":\"...\",\"blockScript\":\"/.../captcha.js?...\"}", "initCookies": { "_px3": "<your flagged token>", "_pxhd": "..." }, "blockUrl": "https://site.com/api/search", "blockMethod": "POST", "proxyType": "http", "proxyAddress": "...", "proxyPort": 8000, "userAgent": "Mozilla/5.0 ..." } ``` Firing the blocked request is what makes the challenge appear: PerimeterX's client renders the press-and-hold only when it sees a monitored request return the ABR block, so `blockUrl` (with the correct `blockMethod`) is required for XHR/ABR sites. For a simple GET endpoint set `blockMethod: "GET"`.

Send the raw HTML block body as `blockData` with `blockMode: "html"`. Unlike the XHR/ABR case, you do NOT need `blockUrl`: the HTML block page already embeds your session globals (`window._pxAppId`, `_pxUuid`, `_pxVid`, and the first-party `captcha.js` path), so we parse them straight out of your HTML and rebuild the Press & Hold widget directly from it. That skips loading the protected page entirely (faster, and it cannot silent-pass), and binds the clearance to YOUR `_pxvid` / `_pxhd` so it validates on replay. Pass your session cookies (especially `_pxhd`) from the blocked response, and replay through the SAME proxy + User-Agent. ```json { "type": "AntiPerimeterXTask", "websiteURL": "https://site.com/protected-page", "blockMode": "html", "blockData": "<!DOCTYPE html> ... the raw 403 Press-and-Hold block page ...", "initCookies": { "_pxhd": "<your _pxhd>", "_pxvid": "<your uuid>" }, "proxyType": "http", "proxyAddress": "...", "proxyPort": 8000, "userAgent": "Mozilla/5.0 ..." } ``` If your HTML block does not embed those globals, or you cannot capture the block body, just send `websiteURL` + proxy: we navigate the page ourselves, read the widget config live, and render an isolated Press & Hold to solve. Supplying the block is faster and more reliable, but it is optional for HTML.

Yes. For a standard PerimeterX page, send `websiteURL` plus your proxy and nothing changes — the solver navigates the page, trips the press-and-hold if it appears, and returns the clearance cookies. The `blockMode` / `blockData` / `blockUrl` fields are OPTIONAL and only needed for XHR/ABR endpoints where your API call returns a JSON 403 and no page renders a widget. If you do not pass `blockData`, behavior is exactly as before.

PerimeterX clearance cookies (_px3 / _px2 / _pxhd) are cryptographically tied to the IP they were issued to. A token we solved on our pool IP would be rejected the moment your downstream HTTP client called the protected endpoint from your own IP. Supplying your own proxy is the only way the solve is reusable — so we don't ship a ProxyLess variant for PerimeterX. Other captchas (Turnstile, hCaptcha base, GeeTest) aren't IP-bound and DO have ProxyLess variants.

Three flavours of the same proof are returned: `token` (just the highest-priority cookie value), `cookie` (a ready-to-paste `Cookie:` header string with every _px* cookie joined), and `cookies` (the structured array). Most customers using `requests` / `httpx` just want `cookie` — drop it straight into the header.

```json { "cookie": "_px3=<value>; _pxhd=<value>; _pxvid=<uuid>", "userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 ...", "challengePresented": true, "holdDurationSec": 9.4, "uuid": "<the _pxvid value PX bound _px3 to>", "vid": "<usually equal to uuid>", "ipBound": true } ``` For most integrations you just need `cookie` (drop into the `Cookie:` header) and `userAgent` (drop into the `User-Agent:` header). `uuid` + `vid` are returned when the Hold Captcha fires — useful if you need to pin the visitor identity in a downstream session that doesn't use a cookie jar. `challengePresented` / `holdDurationSec` are diagnostic — `true` means the Hold Captcha widget rendered and we held it, `false` means PerimeterX silent-passed our session (cookies valid either way). Make the replay request through the SAME proxy you supplied at solve time.

Yes — that's the primary challenge type our solver handles. PerimeterX's Hold Captcha (officially "HUMAN Challenge", branded since HUMAN Security acquired PerimeterX in 2022) is the press-and-hold button that fires when PerimeterX's risk score crosses a threshold. Under the hood it runs a proof-of-work computation while streaming cursor-variance telemetry during the 8–10s hold. Our solver detects the widget (`#px-captcha`, `[class*="press-and-hold"]`, etc.), holds the button for 8.5–11.0s, and captures the resulting _px3 cookie. The `challengePresented` field in the solution tells you which path minted the cookies: `true` if we exercised the press-and-hold, `false` if our fingerprint passed silently before PerimeterX escalated to the widget.

Newer high-security PerimeterX deployments rotate _px3 every ~60 seconds as part of session continuity scoring. Re-solve when it expires, or use a sticky proxy + a custom HTTP client that mimics Chrome's behavior to refresh _px3 inline.

Use a proxy with good IP reputation; low-trust IPs fail PerimeterX's validation because PerimeterX scores IP trust as a primary signal. Use a sticky session (5-10 min stickiness) so the same IP can be reused for both the solve and your downstream calls.

Strongly recommended for any site that enforces session continuity. `uuid` is the `_pxvid` cookie value on the target page — find it in DevTools → Application → Cookies → `_pxvid`. Pass it on createTask and we pre-seed it on the solver's browser context so PerimeterX issues clearance tied to YOUR visitor. Without it, the cookie belongs to a session PerimeterX won't recognize when your client replays. `vid` is sometimes distinct from `uuid` (read from `window._pxhc.vid`); if you only have `uuid` we use it for both.

PerimeterX re-scores every request, so a valid _px3/_px2 alone won't carry a session that still looks automated. Three things keep a long session clean: (1) Replay from a normal client — an automation-flagged browser (`navigator.webdriver=true`, CDP/Playwright artifacts) gets re-challenged on nearly every page load even with a valid clearance cookie, because PerimeterX re-runs its client fingerprint each load; a plain HTTP client (`requests`/`httpx`) or a non-instrumented browser does not. (2) Pin ONE visitor — pass the SAME `uuid` (`_pxvid`) on every solve and keep that _pxvid in your downstream cookie jar, reusing the `uuid` the solution returns on the next createTask. If each solve mints a fresh _pxvid, PerimeterX sees one IP cycling through many new visitors in seconds, which is itself a bot signal that accelerates blocking. (3) Stay on the same sticky IP and reuse the returned `userAgent` — both are part of what the clearance is bound to. With these in place a continuous session is challenged only occasionally, and a single re-solve with the same `uuid` clears it.

That's the PerimeterX challenge-iframe URL, not the protected page. Hitting it directly returns a ~2 KB empty stub because the press-and-hold widget only renders inside the parent site's context. Pass the URL of the parent page (the actual page the user is trying to access) as `websiteURL`. Capzy now rejects iframe URLs with `ERROR_INVALID_PARAMS` so the misconfig is obvious on the first try.