How a captcha solving API works: task, poll, token

The loop

Every captcha solving API in the reviews on this site runs the same four steps, whatever it charges. You create a task by sending the challenge's identifiers, for a reCAPTCHA or Turnstile widget that's the site key and the URL of the page it sits on. The vendor returns a task id. You poll that id until the task is done. The result is a token, a long string the vendor obtained by solving the challenge on its side.

You then put that token where the widget would have put it, in the hidden form field the page's own script fills for a human, and submit the page. The site's server sends the token to the captcha provider for verification, and if the provider says yes, your request is treated as a solved challenge. CaptchaAI's FAQ describes the same shape in one sentence: submit the site key and page URL through the API and retrieve a valid verification token.

What the token is

The token isn't a password to the site. It's a receipt from the captcha provider saying that a challenge for this site key was passed, and the site checks the receipt with the provider, not with you. Google's verification documentation states that each reCAPTCHA user response token is valid for two minutes and can only be verified once. Cloudflare's Turnstile documentation states that each token is valid for 300 seconds after generation and is single-use; a replayed token is rejected with the error code timeout-or-duplicate.

Those two sentences are the whole contract. A token is good for one submission inside a fixed window, and both the window and the single use are enforced on the provider's server, where nothing you do can change them.

The two limits

Time first. The window opens when the vendor's solver generates the token, not when you receive it. Whatever the solve took is already spent, and so is the time your poll loop waited and the time your own request takes to reach the site. For reCAPTCHA the budget is 120 seconds minus all of that. For Turnstile it's 300 seconds. A vendor that publishes a 60 second ceiling for reCAPTCHA v2, as CaptchaAI does, is telling you that half the window can be gone before the token reaches you.

Single use second. One token, one submission. If your code retries a failed request with the same token, the provider rejects it as a duplicate, and if a proxy or a load balancer replays the request, the same thing happens. Every retry needs a fresh solve, which is a fresh charge at every per-solve vendor.

What goes wrong

Most failures come from the request, not the solver. The site key or the page URL is wrong, so the token is for a different widget. The page uses reCAPTCHA Enterprise and the task was created as standard, or the reverse; CaptchaAI's FAQ names incorrect parameters, domain mismatch and Enterprise configuration conflicts as the usual causes. The token expired in your queue. The token was submitted twice.

Then there's concurrency. A vendor that sells threads rejects requests above the thread count rather than queueing them; CaptchaAI's FAQ names the error, ERROR_NO_SLOT_AVAILABLE. A per-solve vendor has no such wall but charges for every solve, including the ones your retries burn.

What the solver can't fix

A solver returns a valid token. Whether the site then serves you the page depends on things outside the token: the site's own server-side checks, and the network address your request arrives from. Google's Search help page on the unusual-traffic message says shared networks and some VPN and tunnel services get blocked wholesale because Google can't separate abusive from non-abusive traffic on them. That's a challenge rate set by the address, and no solver changes it. The guide on the exit address covers what does.