Question 1

Why isn't there a ProxyLess variant?

Accepted Answer

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.

Question 2

Which cookie do I need?

Accepted Answer

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.

Question 3

What does the solution response look like?

Accepted Answer

```json { "cookie": "_px3=; _pxhd=; _pxvid=", "userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 ...", "challengePresented": true, "holdDurationSec": 9.4, "uuid": "", "vid": "", "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.

Question 4

Do you support PerimeterX Hold Captcha (the press-and-hold widget)?

Accepted Answer

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.

Question 5

Why does _px3 expire so fast?

Accepted Answer

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.

Question 6

What kind of proxy do I need?

Accepted Answer

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.

Question 7

What are `uuid` / `vid` and do I need them?

Accepted Answer

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.

Question 8

I keep getting re-challenged when I browse more pages — how do I keep a session alive?

Accepted Answer

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.

Question 9

I tried passing the iframe URL (iframe.hsprotect.net) and it fails — why?

Accepted Answer

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.

PerimeterX (HUMAN Security) Solver, solved in 5.0s.

Quick Integration

Using the result

1. Send Payload

2. Solving Engine

3. Get Result

Task Parameters

Response Shape

Example response

Error response

Features

Pricing & Stats

Start solving perimeterx (human security).

Frequently asked questions