The task is ready. Why is the reCAPTCHA token rejected?

{
  "id": "example-task",
  "status": "ready",
  "solution": {
    "token": "EXAMPLE_TOKEN",
    "userAgent": "EXAMPLE_USER_AGENT",
    "secChUa": "EXAMPLE_CLIENT_HINTS"
  }
}

In this example, solution.token is the value to submit wherever the target expects its reCAPTCHA token. id identifies the solvethree task; it isn't a token. Don't send the whole solution object either.

Inspect the final outgoing request, not just the variable holding the response. Check that it contains the current token, rather than an empty value or an older token left in the form. Keep tokens out of shared logs.

The submitted token is correct, but the target still rejects it.

Compare the task's site hostname with the hostname of the protected request. Look for a different subdomain or environment.

Try this: Request the token for the intended hostname and submit it to that target. The target site must have an active profile available to your workspace.

A token requested for one interaction is used for another.

Compare the task's action with the exact action expected for this protected request.

Try this: Use the action associated with the interaction you're submitting.

The integration uses the wrong reCAPTCHA variant.

Inspect recaptchaType in the task request. It defaults to enterprise-v3; the gateway also accepts v3.

Try this: Match the target's product explicitly. For Enterprise v3, use enterprise-v3.

Both classic reCAPTCHA and reCAPTCHA Enterprise website response tokens expire after two minutes and are single-use. Classic tokens can be verified once; Enterprise tokens can be assessed once. Solve near the protected request rather than keeping a stock of ready tokens.

• If submission happens after a delay, check how much time passed between solving and sending the token.
• If the token was already verified or assessed, don't reuse it for another submission.
• Don't run a separate verification or Enterprise assessment merely to test the token before sending it to the target. That test can consume it.

Solving succeeds, but submission uses another connection.

Compare the proxy used successfully for the solve with the proxy used for the protected request. If you supplied proxyCandidates, don't assume the first candidate succeeded.

Try this: Submit through the successful proxy. Switching IPs between solving and submission can break the request.

The submitting client uses its own default browser headers.

Inspect the outgoing User-Agent and Sec-CH-UA values against solution.userAgent and solution.secChUa.

Try this: Use the returned browser identity together with the successful proxy. Don't combine the token with unrelated user-agent or client-hint values.

Inspect the target's response body as well as its HTTP status. A 403 alone doesn't identify which protection rejected the request. Look for an explicit token error or a hostname/action mismatch before requesting another token.

If verification details are available, check classic reCAPTCHA's success result and returned context/error information. For Enterprise, inspect token validity and relevant assessment reasons. Don't assume a score by itself explains rejection: the website decides how to use the assessment.

If you still can't identify the cause, contact [email protected] with the task ID and requestId if used, product, timestamp, target hostname/action, HTTP status or task error, and a sanitized description of the response. Remove API keys, proxy passwords, tokens, cookies and customer data.