Solving enterprise hCaptcha (rqdata): why it's hard.

Enterprise hCaptcha binds every challenge to a fresh rqdata blob and the session it was issued in. A token is only valid if it was minted against that exact rqdata, which is why solving the image grid alone is not enough and why a purpose-built hCaptcha solver beats an image-recognition API here.

What rqdata actually is

On a regular hCaptcha sitekey, the widget renders, the visitor (or an invisible check) passes, and hCaptcha injects a P1_ token into the h-captcha-response field. The token mostly answers one question: was a challenge passed for this sitekey?

Enterprise sitekeys add a second input. The page passes a signed, per-challenge blob called rqdata into hcaptcha.render() or hcaptcha.execute(). That blob encodes session and request context, and it changes on every challenge. The token hCaptcha returns is bound to the rqdata it was issued against, so verification now answers a stricter question: was this challenge passed for this exact rqdata, in this session? Feed a solver stale or mismatched rqdata and the resulting token is invalid even though the grid was answered correctly.

<!-- The enterprise sitekey passes a fresh rqdata blob into render(). -->
<script>
  hcaptcha.render('captcha-box', {
    sitekey: 'f5ab1c2d-7e8f-4a9b-b1c2-d3e4f5a6b7c8',
    rqdata: 'eyJ0eXAiOiJKV1QiLCJhbGciOiJI...A_per_session_blob',
  });
</script>

<!-- after a solve, hCaptcha injects the token as usual: -->
<textarea name="h-captcha-response">P1_eyJ0eXAi...UV8w</textarea>

Regular vs enterprise at a glance

Why enterprise is harder than regular hCaptcha

The difficulty is not the image grid. It is the binding around it. An enterprise token has to satisfy three things at once:

• The challenge was passed. Same as regular hCaptcha: the grid (or invisible check) has to clear.
• It was passed against the live rqdata. The blob is single-use and per-challenge. A token minted a moment too late, or against a different render, does not verify.
• The session lines up. Enterprise deployments commonly check that the IP and session that solved the challenge match the ones submitting the token. Solver vendors reflect this: NopeCHA, for example, tells users to pass a proxy that matches the submit IP because, in its words, "most sites will check that the IP used to solve the challenge matches the IP used to submit the token."

Token validity is still short. An hCaptcha token is good for roughly 120 seconds and is single-use, so the whole capture, solve, and submit loop has to happen inside that window. With regular hCaptcha you have some slack. With enterprise you have less, because the rqdata behind it is also expiring.

Why image-recognition APIs struggle here

A pure token or image-recognition service treats a captcha as a vision problem: receive the challenge images, classify them, return the answer. That works for the regular variant, where the question really is "which tiles match." Enterprise rqdata moves the goalposts. The token has to be bound to the exact session the rqdata was issued for, not just derived from the images. Recognising the grid in isolation does not give you that. You can answer every tile correctly and still get an invalid token, because the token never matched the blob.

This is the same reason in-browser stealth tricks fall down on enterprise sitekeys. A patched automation browser can sometimes pass a regular challenge, but it cannot easily produce the session signals an enterprise rqdata flow expects. See solving hCaptcha in Playwright for why the reliable pattern is to mint the token out of band rather than fight the challenge inside the browser you are automating.

How NoneCap mints enterprise tokens

NoneCap does not classify images in a vacuum. It returns a finished token bound to the exact rqdata you pass in, the kind enterprise sitekeys accept and image-recognition output does not. You send the enterprise type with the per-challenge rqdata alongside the sitekey and url. Block for the result with ?wait=N (up to 90 seconds) or pass a webhook_url for async jobs:

curl "https://api.nonecap.com/v1/solves?wait=90" \
  -H "Authorization: Bearer $NONECAP_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "type":    "hcaptcha_enterprise",
    "sitekey": "f5ab1c2d-7e8f-4a9b-b1c2-d3e4f5a6b7c8",
    "url":     "https://target.example/login",
    "rqdata":  "eyJ0eXAiOiJKV1QiLCJhbGciOiJI...A_per_session_blob"
  }'

{
  "id":              "solve_01HQF7K3JKWZX",
  "object":          "solve",
  "type":            "hcaptcha_enterprise",
  "status":          "solved",
  "sitekey":         "f5ab1c2d-7e8f-4a9b-b1c2-d3e4f5a6b7c8",
  "url":             "https://target.example/login",
  "token":           "P1_eyJ0eXAi...UV8w",
  "credits_charged": 2
}

The response is the standard solve object with type: "hcaptcha_enterprise" and a real P1_ token in the token field. Submit it as the page's h-captcha-response exactly as you would a regular token. Capture the rqdata fresh for each challenge, since it is single-use and tied to that session. The full object and every language sample are in the API reference.

This is where NoneCap is strongest

Enterprise rqdata is the differentiator. It is the case that breaks image-only solvers and the reason a purpose-built hCaptcha solver matters. If you are evaluating alternatives, this is the axis to test them on:

• Against a subscription extension-style service, see NoneCap vs NopeCHA, where enterprise tokens pass verification rather than relying on image recognition.
• Against a broad human-and-AI marketplace, see NoneCap vs 2Captcha, where hCaptcha is the headline product rather than one type among many.

When a token-only API is enough

Be honest about the sitekey in front of you. If it is a regular hCaptcha sitekey with no rqdata, you do not need any of this. A plain image-recognition API, or NoneCap's standard type: "hcaptcha", will return a valid token, and cheaper broad solvers may be perfectly fine. The enterprise machinery only earns its keep when the page passes rqdata and binds the session. And if your target is reCAPTCHA, Cloudflare Turnstile, or FunCaptcha, NoneCap does not solve those yet (they are on the roadmap), enterprise or otherwise.