PRODUCT TEST WORKSPACE

GeeTest v4

Captcha verification product

GEETEST_V4

02 / REQUEST

Request preview

POST /api/validator/create.cgi

{
  "productCode" : "GEETEST_V4",
  "adapter" : {
    "websiteURL" : "https://example.com/register",
    "captchaId" : "YOUR_CAPTCHAID"
  }
}

03 / RESULT

Response example

EXAMPLE

Task ID —

{
  "code" : 0,
  "msg" : "Success",
  "data" : {
    "taskId" : "11111111-1111-4111-8111-111111111111",
    "productCode" : "GEETEST_V4",
    "state" : "SUCCEEDED",
    "solution" : {
      "captcha_id" : "EXAMPLE_CAPTCHA_ID",
      "lot_number" : "EXAMPLE_LOT_NUMBER",
      "pass_token" : "EXAMPLE_PASS_TOKEN",
      "gen_time" : "EXAMPLE_GEN_TIME",
      "captcha_output" : "EXAMPLE_CAPTCHA_OUTPUT"
    }
  }
}

Illustrative response; not a live task result. Replace all request placeholders before submitting.

Read data.solution after state becomes SUCCEEDED. The solution fields depend on the product; other states may return an empty object.

04 / API REFERENCE

GeeTest v4 · API

For task creation and queries, send the API key in the apiKey HTTP header. JSON request bodies contain business parameters only.

Content-Type: application/json
apiKey: YOUR_API_KEY

Result and application

STRUCTURED_PROOF

Use GEETEST_V4 for initGeetest4/captcha_id; use GEETEST for the v3 gt/challenge flow. Preserve captcha_id, lot_number, pass_token, gen_time and captcha_output as a matching group and submit through the target v4 integration.

Conditional workflows

HTTP submission HTTP_SUBMIT
Apply a result in the browser BROWSER_RESULT

Requirements

Prefer the product-specific (native) CAPTCHA integration over generic GRID. Identify the actual product/version and read its schema/guide before choosing. Use HTTP_SUBMIT when the target supports it, otherwise BROWSER_RESULT when the browser can apply the native result. Image grids on screen do not by themselves mean the product is GRID. Collect real inputs; missing inputs are a blocker, not permission to guess.
Apply a native result through the matching target integration: fill the expected token response field/callback, or use the returned challenge identifier and proof/answer fields together where that product requires them. Preserve the target session and bindings. Do not mix old and new challenge fields, replace only a picture, or assume the solver issues an unrelated transferable challenge/answer pair.
Use GEETEST_V4 for initGeetest4/captcha_id; use GEETEST for the v3 gt/challenge flow. Preserve captcha_id, lot_number, pass_token, gen_time and captcha_output as a matching group and submit through the target v4 integration.
For PROVIDER_UNSOLVABLE, inspect the precise version, initialization source, challenge consumption/expiry, API hostname, actual User-Agent and target session. Different challenge values do not prove freshness. Solver failure occurs before any successful proof can be applied. A changed challenge is a new paid task, not a transport retry.
Collect fresh values from the same target/challenge. Respect product-specific hostname, action, challenge/session, IP, User-Agent and expiry requirements; these are not universally interchangeable. Apply returned cookies only to their matching domains.
Examples are placeholders, not runnable challenges. Documented result fields are not proof of target acceptance or a live availability test. Do not send unsupported fields.
SUCCEEDED means a solver result is available. Separately confirm that the target accepts the challenge and that the requested business operation completes. The solver cannot observe those two outcomes.

Input sources

Field	Input sources
`websiteURL`	Read from the actual target page, widget configuration or documented integration. Identify the precise product/version; placeholders and keys from another site cannot be substituted.
`captchaId`	Use the captcha_id from the target initGeetest4 configuration. It is not the gt or challenge of a v3 integration.
`userAgent`	Read the actual User-Agent used to obtain this challenge; preserve it when the product requires matching.
`riskType`	Optional actual GeeTest v4 risk_type. Sent inside upstream initParameters with captcha_id; it does not change the product version.

Request example

POST /api/validator/create.cgi · JSONC

{
  "productCode": "GEETEST_V4", // Product code matching the adapter parameters.
  "adapter": { // Product-specific parameter object.
    "websiteURL": "https://example.com/register", // Full URL of the page containing the challenge.
    "captchaId": "YOUR_CAPTCHAID" // Use the captcha_id from the target initGeetest4 configuration. It is not the gt or challenge of a v3 integration.
  }
}

Request headers: apiKey: YOUR_API_KEY

Comments explain the fields. Copy produces valid JSON without comments.

Response example

POST /api/validator/query.cgi · JSONC

{
  "code": 0, // Business result code: 0 means success; other values indicate an error.
  "msg": "Success", // Result message; may be empty on success.
  "data": { // Response data; may be null on an error.
    "taskId": "11111111-1111-4111-8111-111111111111", // Task ID returned by task creation.
    "productCode": "GEETEST_V4", // Product code matching the adapter parameters.
    "state": "SUCCEEDED", // Task state: CREATED, SUBMITTING, PROCESSING, SUCCEEDED, FAILED or EXPIRED.
    "solution": { // Product answer when SUCCEEDED; empty while processing or on failure.
      "captcha_id": "EXAMPLE_CAPTCHA_ID", // Product-specific answer field; use it according to the target website verification protocol.
      "lot_number": "EXAMPLE_LOT_NUMBER", // Product-specific answer field; use it according to the target website verification protocol.
      "pass_token": "EXAMPLE_PASS_TOKEN", // Verification token to submit to the target website.
      "gen_time": "EXAMPLE_GEN_TIME", // Product-specific answer field; use it according to the target website verification protocol.
      "captcha_output": "EXAMPLE_CAPTCHA_OUTPUT" // Product-specific answer field; use it according to the target website verification protocol.
    }
  }
}

Creating a task returns its ID and initial state. Query the result or use WebSocket to receive the completed answer shown below.

Request parameters

Field	Type	Required	Description
`productCode`	string	Yes	Product code matching the adapter parameters.
`adapter`	object	Yes	Product-specific parameter object.
`adapter.websiteURL`	string	Yes	Full URL of the page containing the challenge.
`adapter.captchaId`	string	Yes	Use the captcha_id from the target initGeetest4 configuration. It is not the gt or challenge of a v3 integration.
`adapter.userAgent`	string	No	User-Agent of the browser that obtained the challenge.
`adapter.riskType`	string	No	Optional actual GeeTest v4 risk_type. Sent inside upstream initParameters with captcha_id; it does not change the product version.

Response parameters

Field	Type	Description
`code`	integer	Business result code: 0 means success; other values indicate an error.
`msg`	string	Result message; may be empty on success.
`data`	object \| null	Response data; may be null on an error.
`data.taskId`	string	Task ID returned by task creation.
`data.productCode`	string	Product code matching the adapter parameters.
`data.state`	string	Task state: CREATED, SUBMITTING, PROCESSING, SUCCEEDED, FAILED or EXPIRED.
`data.solution`	object	Product answer when SUCCEEDED; empty while processing or on failure.
`data.failure`	object \| omitted	Public diagnosis for FAILED/EXPIRED only; no raw provider messages. Follow the failure handling guide.
`data.failure.code`	string	Failure code
`data.failure.nextAction`	string	Next action
`data.solution.captcha_id`	string	Product-specific answer field; use it according to the target website verification protocol.
`data.solution.lot_number`	string	Product-specific answer field; use it according to the target website verification protocol.
`data.solution.pass_token`	string	Verification token to submit to the target website.
`data.solution.gen_time`	string	Product-specific answer field; use it according to the target website verification protocol.
`data.solution.captcha_output`	string	Product-specific answer field; use it according to the target website verification protocol.

Responses

HTTP business responses contain code, msg and data; code 0 means success. WebSocket uses a separate message structure.

-1317: Invalid API key.
-1100 / -1101: Invalid or missing request parameters.
-1401: Insufficient balance. Add funds before creating a task.
-1400 / -1001: System or task creation error.

API documentation

GeeTest v4

Create task

Request preview

Response example

GeeTest v4 · API

Request example

Response example

Request parameters

Response parameters

Responses