CordNitroRedeemToken
Solve the hCaptcha challenge Cord serves on the gift-redeem endpoint, and get back both headers needed to replay the redeem.
Cord gates gift and Nitro redemption behind an enterprise hCaptcha bound to a one-time rqdata value.
CordNitroRedeemToken solves that specific challenge: you pass the sitekey and rqdata from Cord's rejection,
and get back the x-captcha-key and x-captcha-rqtoken pair to replay the redeem with.
It takes the same inputs as PopularCaptchaEnterpriseToken, but the solve runs through a flow tuned for the redeem endpoint. Both are priced identically, so choose by endpoint, not by cost: use this task for gift and Nitro redeems, and the enterprise solve for every other Cord challenge (login, verification, server actions).
Use a sticky proxy
The solve and the redeem must come from the same exit IP. Rotating proxies put the two requests on different addresses, which Cord scores as suspicious. A mid-task IP change can also expose the account token.
Finding the parameters
Cord answers a blocked redeem with 400 and the challenge in the body:
{
"captcha_key": ["captcha-required"],
"captcha_sitekey": "a9b5fb07-92ff-493f-86fe-352a2803b3df",
"captcha_rqdata": "rX5Jrmm4ylfrnE8lx2COFH83kzM058+EHak3N+1eegOF70r...",
"captcha_rqtoken": "Ikx3bjdxNTBDVUptUzBScWdHYzZRSVRabjUzUUw2U0JOR3ppemd..."
}Send captcha_sitekey as websiteKey and captcha_rqdata as rqdata.
rqdata is single-use
Each captcha_rqdata is bound to one challenge. Re-fetch it from a fresh 400 for every attempt; replaying an old
value fails the solve.
Replaying the redeem
Retry the redeem request with both values from the solution:
X-Captcha-Key: <solution.token>X-Captcha-Rqtoken: <solution.rqToken>
Cord rejects the retry if either header is missing.
Supported Providers
| Provider | Price per 1,000 | Routing |
|---|---|---|
 | $10.00 |
Request Schema
| Field | Type | Required | Description |
|---|---|---|---|
clientKey* | string | Yes | Your API key. Create one in the AnySolver dashboard. Example: |
task* | object | Yes | The task body. Required fields depend on the task type. See Tasks for per-task schemas. View task properties |
settings | object | No | Per-request settings for routing, auto retry, auto fallback, and proxy behavior. See Routing Strategies. View settings reference |
Task Object Properties
The task field accepts an object with the following properties:
| Field | Type | Required | Description |
|---|---|---|---|
type* | Yes | ||
websiteKey* | string | Yes | hCaptcha sitekey Cord returns with the redeem challenge. Example: |
rqdata* | string | Yes | The Example: |
proxy* | string | object | Yes |
Optional fields are not guaranteed across providers
Response Schema
| Field | Type | Required | Description |
|---|---|---|---|
status* | Yes | Task status: "processing", "ready", or "failed". Example: | |
errorId* | Yes | 0 = success, 1 = external error, 2 = internal error. Example: | |
taskId | string | No | Unique identifier returned when the task was created. Example: |
errorCode | No | Machine-readable error code. Example: | |
errorDescription | string | No | Human-readable error message with resolution hints. Example: |
cost | number | No | Actual cost charged for this task in USD. Example: |
taskType | No | The type of CAPTCHA task to solve. Example: | |
provider | No | Provider that handled this task. While processing, the provider currently solving it. Example: | |
solution | object | No |
Solution Object Properties
The solution field contains an object with the following properties:
| Field | Type | Required | Description |
|---|---|---|---|
token* | string | Yes | The solved CAPTCHA token to submit with your form. Example: |
raw* | Record<string, unknown> | Yes | Raw provider response data for advanced use cases. |
rqToken | string | No | Companion |