Migration

Already on 2Captcha or Anti-Captcha? SurSolver uses the same createTask / getTaskResult shape, with clientKey in the body and the errorId response fields. Check each item under What to adjust, because the flow differs in places. The first two lines to change:

- API = "https://api.2captcha.com"
+ API = "https://api.sursolver.com"
- KEY = "YOUR_2CAPTCHA_KEY"
+ KEY = "YOUR_SURSOLVER_KEY"

Anti-Captcha integrations change their own host the same way:

- API = "https://api.anti-captcha.com"
+ API = "https://api.sursolver.com"
- KEY = "YOUR_API_KEY"
+ KEY = "YOUR_SURSOLVER_KEY"

What stays the same

• POST {base}/createTask with {"clientKey": …, "task": {"type": …, …}}, answering {"errorId":0,"taskId":…,"status":"idle"}.
• POST {base}/getTaskResult with {"clientKey": …, "taskId": …}, answering processing while the task runs and ready with a solution object when it is done.
• POST {base}/getBalance with {"clientKey": …}, answering {"errorId":0,"balance":…} in USD.
• errorId: 0 on success and errorId: 1 with errorCode / errorDescription on a reported failure, in an HTTP 200 reply. Unexpected server errors are the exception: HTTP 500 without errorId — see Errors.
• The solution keys of each type (gRecaptchaResponse, token, cookies, …).

What to adjust

Names. task.type is matched case-insensitively, and the Task / TaskProxyLess / Token suffixes are ignored, so ReCaptchaV2TaskProxyLess and recaptchav2 reach the same service. Not every name from another API resolves, though: only the names listed in the public catalog (GET /v1/task-types) are accepted, so check each task.type you send against it. An unlisted name answers ERROR_TYPE_NOT_SUPPORTED.

Failures. SurSolver returns its own error catalogue. An execution time limit answers ERROR_TASK_TIMEOUT; other upstream failures answer ERROR_FAILED with the reason in errorDescription. Vendor-specific codes such as ERROR_CAPTCHA_UNSOLVABLE do not exist here.

Timing. Every task is asynchronous: there is no one-call synchronous getToken-style endpoint, and no inline result in createTask. Poll getTaskResult every 3 seconds.

Proxies. Proxy details travel in the same task object, but the four-part colon string is always read as user:password:host:port here. Some clients send host:port:user:pass instead; this API does not detect the order, so such a string may be accepted and misread — or rejected with ERROR_INVALID_REQUEST. Convert those strings, or send the split proxyType / proxyAddress / proxyPort / proxyLogin / proxyPassword fields, which is the recommended form when migrating. Modes and formats per type: Proxies.

Charging. A task is charged when accepted. A failed task automatically returns its original charge once. A successful task retains its charge; internal retries do not add charges.

Not offered. Callback/webhook delivery (callbackUrl is not part of this surface — poll instead), image and text recognition tasks, and the reportIncorrect… complaint methods. appId is accepted for the referral program; other vendors’ softId is not.

Migration checklist

1. Create a SurSolver key in the dashboard and put it behind the same secret store as the old one.
2. Point the base URL at https://api.sursolver.com.
3. Replace the task.type values with the names from GET /v1/task-types.
4. Keep the polling loop, and stop it on the first errorId: 1.
5. Re-check proxy handling for the types you use — proxy fields and modes are in GET /v1/task-types and in Proxies.
6. Run one task end to end against the live API before switching traffic, and confirm the charge with getBalance.