GeeTest v3 challenge parameters: a CapBypass field reference

GeeTest v3 integrations fail most often before a solver receives a request. A stable gt value paired with a stale, missing, or mismatched challenge value is not the documented v3 input contract. This field reference maps the values required for GeetestTaskProxyLess so an authorized integration can validate its handoff before it calls CapBypass.

Choose the documented v3 task

CapBypass documents GeetestTaskProxyLess for a GeeTest task that uses CapBypass proxy infrastructure. The active pricing catalogue lists that exact task type as active. The same documentation distinguishes the v3 flow from v4: v3 uses gt plus challenge, while v4 uses captchaId. Do not send a v4 captchaId to a v3 task payload and do not manufacture a challenge from a page URL.

The request endpoint is https://api.capbypass.pro/createTask. Its top-level clientKey is the CapBypass API key. The task object needs type, websiteURL, gt, and challenge for the v3 flow. websiteURL identifies the authorized page serving the challenge. Keep the value as the page URL, not a guessed API endpoint or a redirect destination.

Parameter reference

Field	Required for GeeTest v3	What to provide
clientKey	Yes	Your CapBypass API key. Keep it in server-side configuration.
task.type	Yes	The exact string GeetestTaskProxyLess.
task.websiteURL	Yes	The URL of the authorized page that serves the GeeTest challenge.
task.gt	Yes	The site-specific GeeTest identifier for the v3 flow.
task.challenge	Yes	The request-time challenge value issued by the target site's backend.

The important timing rule is in the official GeeTest documentation: gt is constant per site, but challenge is fresh per request. Capture both from the same authorized user flow. When a request is retried after a page refresh or a new registration response, obtain the current challenge again. Reusing an old value because the gt value still matches is a common source of invalid task input.

Create the task

This curl request contains the complete documented createTask shape. Replace only CAPBYPASS_CLIENT_KEY, the authorized page URL, and the current values from that page's own v3 flow. The example values below are deliberately non-production values.

curl -sS -X POST https://api.capbypass.pro/createTask \
  -H 'Content-Type: application/json' \
  -d '{
    "clientKey": "CAPBYPASS_CLIENT_KEY",
    "task": {
      "type": "GeetestTaskProxyLess",
      "websiteURL": "https://example.com/login",
      "gt": "81388ea1fc187e0c335c0a8907ff2625",
      "challenge": "7b33c5254c55c432cf558767e36b8ef5"
    }
  }'

A successful create response supplies a task identifier. Store that identifier with the request context that produced the current challenge. Do not attach it to a later page load with a different challenge. The documented result endpoint is https://api.capbypass.pro/getTaskResult; send the same clientKey and the task identifier returned by createTask.

Poll with a bounded loop

A polling loop should distinguish a not-ready response from a malformed request or terminal error. The following Python example uses only the standard library and exits after a fixed number of attempts. It keeps the key in an environment variable and sends the exact task type and v3 fields documented by CapBypass.

import json
import os
import time
from urllib.request import Request, urlopen

BASE_URL = "https://api.capbypass.pro"
CLIENT_KEY = os.environ["CAPBYPASS_CLIENT_KEY"]

def post(path, payload):
    request = Request(
        BASE_URL + path,
        data=json.dumps(payload).encode("utf-8"),
        headers={"Content-Type": "application/json"},
        method="POST",
    )
    with urlopen(request, timeout=30) as response:
        return json.load(response)

created = post("/createTask", {
    "clientKey": CLIENT_KEY,
    "task": {
        "type": "GeetestTaskProxyLess",
        "websiteURL": "https://example.com/login",
        "gt": "81388ea1fc187e0c335c0a8907ff2625",
        "challenge": "7b33c5254c55c432cf558767e36b8ef5",
    },
})
task_id = created["taskId"]

for attempt in range(12):
    result = post("/getTaskResult", {
        "clientKey": CLIENT_KEY,
        "taskId": task_id,
    })
    if result.get("status") == "ready":
        print(json.dumps(result["solution"], indent=2))
        break
    if result.get("status") != "processing":
        raise RuntimeError(json.dumps(result))
    time.sleep(2)
else:
    raise TimeoutError("GeeTest task did not become ready in time")

Validate the handoff before calling the API

Use a small server-side checklist at the boundary between the page flow and your task request. First, confirm that the intended flow is GeeTest v3, not v4. Second, require a nonempty gt and a nonempty challenge. Third, associate the challenge with the current page or registration response. Finally, submit the returned solution only to the authorized verification endpoint that issued the challenge.

Avoid logging the API key, the full challenge payload, or a returned solution in application logs. Log a request correlation identifier, the selected task type, and whether the result was ready instead. That evidence is enough to diagnose a stale handoff without exposing reusable values.

The official documentation says that the v3 result is submitted as geetest_challenge, geetest_validate, and geetest_seccode form parameters to the target site's verification endpoint. Preserve the names and use the solution only within the matching authorized flow. A value from one flow is not a general-purpose credential for another page.

---

Bonus: +5% credits on every top-up

New to CapBypass? Apply code WELCOME_2026 at checkout for an extra 5% in credits on every top-up, with no minimum and no expiry. Redeem it on the top-up page.

---

Quick diagnostics

If createTask rejects a request, compare the payload with the field table before changing retry behavior. Verify the exact casing of GeetestTaskProxyLess, confirm that websiteURL is the page URL, and ensure that the current v3 flow produced both gt and challenge. If a task remains processing past the application's bound, record the task identifier internally and stop the loop rather than creating duplicate tasks. When a page has refreshed, treat its new challenge as new input and begin a new authorized request context.

For the complete task examples and the v3 versus v4 input distinction, use the current GeeTest documentation.