DEV Community: Bassem Shahin

Why your reCAPTCHA v3 score is low — and how to actually raise it

Bassem Shahin — Thu, 25 Jun 2026 08:14:51 +0000

Why your reCAPTCHA v3 score is low — and how to actually raise it

reCAPTCHA v3 is the one that never shows a checkbox or a puzzle. Instead it watches the whole session and hands the site a score from 0.0 to 1.0 — roughly "how human does this look." The site then decides what to do with it (allow, step up, block) based on its own threshold. So when your automation "fails reCAPTCHA v3," there's nothing to click — you're just scoring too low. The fix is understanding what it scores.

What v3 is actually scoring

v3 doesn't test whether you can solve something. It builds a risk score from signals across the page load and session:

IP reputation — datacenter ranges score low almost by default; residential/mobile score higher.
Browser fingerprint — navigator.webdriver, headless/automation tells, missing or inconsistent client-hints, a TLS/JA3 that doesn't match the UA you claim.
Behavior + history — mouse movement, timing, whether you have Google cookies / a browsing history, how you arrived at the page.
The action parameter — v3 tags each execution with an action (e.g. login); a mismatch or a generic action looks off.

The key mental model: a low score is a "you look automated" verdict, assembled before you ever submit. There's no token to "solve" your way past it — you raise the score or you produce a token that already scores high.

Why yours is low (the usual suspects)

Running from a datacenter IP (AWS/GCP/cloud) — the single biggest score killer.
Default Selenium/Playwright — leaks navigator.webdriver + CDP/headless artifacts.
A cold session — no cookies, no history, straight to the protected action.
Machine-speed behavior — instant navigation/clicks, no human-ish timing.
Fingerprint mismatch — a Chrome UA over a Pythonrequests TLS fingerprint, or a geo/timezone that disagrees with the IP.

How to actually raise it

Fix the IP first — residential/mobile, geo-consistent with the rest of the profile. This alone moves the score the most.
Kill the automation tells — a stealth/patched browser (or a real one) so navigator.webdriver is false, client-hints are consistent, and the TLS fingerprint matches the UA.
Warm the session — keep cookies, do a little real navigation before the scored action, don't jump straight to the endpoint.
Human-ish behavior — realistic timing and interaction, not perfect machine cadence.
Use the right action — match the action the site expects for that step.

For automation that still scores too low after the fundamentals, the practical route is to fetch a token from a solving service that produces high-scoring v3 tokens, then submit it. One important nuance people miss: the minimum score is set by the target site, not by you or the solver — so you can't "request 0.9"; you produce the best token possible and the site's threshold decides. Getting the fundamentals right is what makes that token land above their cutoff.


import requests, time

API_KEY, SITEKEY, PAGEURL = "YOUR_API_KEY", "6Lc...", "https://target.example/login"

rid = requests.post("https://ocr.captchaai.com/in.php", data={

    "key": API_KEY, "method": "userrecaptcha",

    "version": "v3", "action": "login",

    "googlekey": SITEKEY, "pageurl": PAGEURL, "json": 1,

}).json()["request"]

token = None

for _ in range(40):

    time.sleep(3)

    res = requests.get("https://ocr.captchaai.com/res.php", params={

        "key": API_KEY, "action": "get", "id": rid, "json": 1}).json()

    if res["status"] == 1:

        token = res["request"]; break

# submit token as g-recaptcha-response for the matching action

TL;DR

v3 gives a 0.0–1.0 score, not a puzzle — a low score means "looks automated," assembled from IP + fingerprint + behavior.
Biggest levers, in order: residential geo-matched IP → no automation fingerprint → warm session → human-ish behavior → correct action.
The site sets the min-score threshold, not you — so fix the fundamentals; a token only lands if the rest looks legit.

If you want to test the token flow against your own target, CaptchaAI returns reCAPTCHA v3 tokens (with action) and is 2Captcha-API-compatible, so an existing client is mostly a base-URL change — the trial is free (3 days, no card).

Migrating reCAPTCHA solving off 2Captcha: the one-line swap (and what changes at volume)

Bassem Shahin — Wed, 24 Jun 2026 08:56:41 +0000

Migrating reCAPTCHA solving off 2Captcha: the one-line swap

Most teams who solve reCAPTCHA at volume started on 2Captcha. What people don't realize is that the 2Captcha API has effectively become a shared interface — several providers implement the same in.php / res.php contract. So switching usually isn't a rewrite; it's a base-URL change.

This matters because the main reason to switch is cost at volume (per-1,000 scales linearly; thread-based flattens it). If migrating were a big refactor the savings wouldn't be worth it. It isn't, so they are.

The actual diff

Typical 2Captcha reCAPTCHA code:


import requests, time

API_KEY = "YOUR_KEY"

BASE = "https://2captcha.com"          # the only provider-specific line

submit = requests.get(f"{BASE}/in.php", params={

    "key": API_KEY, "method": "userrecaptcha",

    "googlekey": SITE_KEY, "pageurl": PAGE_URL})

task_id = submit.text.split("|")[1]

while True:

    r = requests.get(f"{BASE}/res.php", params={"key": API_KEY, "action": "get", "id": task_id})

    if r.text == "CAPCHA_NOT_READY": time.sleep(5); continue

    token = r.text.split("|")[1]; break

Migrating to a 2Captcha-compatible provider:


BASE = "https://ocr.captchaai.com"     # changed

API_KEY = "YOUR_NEW_KEY"               # changed

# everything else is byte-for-byte identical

method=userrecaptcha, googlekey, pageurl, the OK| response, CAPCHA_NOT_READY polling, the token — all the same. Wrapped it in a client class? Change one constant. Used an SDK? Point it at the new base URL.

What stays identical

The reCAPTCHA flow: v2 checkbox, v2 invisible, v3 version=v3 + min_score) — same call shape.
Token handling, your retry/timeout/polling logic — untouched.

What changes

The pricing model (the point): per-1,000 → per-thread with unlimited solves. Size for peak concurrency, not monthly total.
Latency / success-rate are provider-specific — so measure, don't assume.

How to migrate without betting the pipeline on it

Keep 2Captcha wired in; add the new provider behind the same interface (same calls — trivial).
Route ~10% of traffic to the new one.
Compare on your targets: success rate, median latency, cost per 1,000.
Holds up? Ramp. Doesn't? You've lost nothing.

Because the API is identical, that A/B harness is a few lines and a flag.

The honest version

A compatible provider is a drop-in at the API level — that part is a one-line swap. Whether it's the right swap depends on your numbers: run the A/B on real traffic and let the data decide. Compatibility just makes that test cheap.

The real cost of solving reCAPTCHA at scale (per-1,000 vs thread-based)

Bassem Shahin — Tue, 23 Jun 2026 16:23:28 +0000

The real cost of solving reCAPTCHA at scale

If you automate anything on the public web for long enough, reCAPTCHA is the wall you hit most. It's on far more sites than Turnstile, hCaptcha, or the enterprise bot vendors combined. So when you wire in a solving service, the interesting question usually isn't "can it solve reCAPTCHA" (most can). It's what does it cost when you're doing this 100,000 times a month — or 10 million?

That's where the pricing model matters more than the per-solve price.

Two ways solvers bill you

Per-1,000 solves (usage-based). 2Captcha, Anti-Captcha, CapSolver, CapMonster — most of the market — charge per solve, quoted per 1,000 (~$1–$3 for reCAPTCHA). Your bill scales linearly with volume. Double the traffic, double the cost. Forever.
Thread-based (concurrency-based). A "thread" is one concurrent in-flight solve. You buy N threads and get unlimited solves per thread per month. Cost scales with peak concurrency, not total volume — so once sized, pushing more solves through is free.

The math

reCAPTCHA v2 at ~$2 per 1,000 vs thread-based tiers (illustrative — check current pricing):

|---|---|---|---|---|

| 10,000 | ~$20 | 5 threads | ~$15 | ~$1.50 |

| 100,000 | ~$200 | 5 threads | ~$15 | ~$0.15 |

| 1,000,000 | ~$2,000 | 50 threads | ~$90 | ~$0.09 |

| 10,000,000 | ~$20,000 | 200 threads | ~$300 | ~$0.015 |

The usage column grows in a straight line. The thread column barely moves. At a million/month the effective per-1,000 is single-digit cents; at ten million it's a rounding error.

When each wins

Low/bursty volume → usage-based (or a free tier). A few thousand a month with idle gaps? Pay per solve; you're not paying for concurrency you don't use.
Sustained/high volume → thread-based. Solving continuously? Flat per-thread wins, and the gap widens the more you push.

The one ask of thread-based: size threads to peak concurrency, not total volume. Watch your live concurrency for a day, buy ~that many, done.

The token flow (so this isn't just pricing)

reCAPTCHA v2/v3 is the same three steps regardless of vendor — and on a 2Captcha-compatible API it's identical calls:


import requests, time

API_KEY = "YOUR_KEY"

BASE = "https://ocr.captchaai.com"   # 2Captcha-compatible

r = requests.get(f"{BASE}/in.php", params={

    "key": API_KEY, "method": "userrecaptcha",

    "googlekey": "SITE_KEY", "pageurl": "https://target.example/login"})

task_id = r.text.split("|")[1]

while True:

    res = requests.get(f"{BASE}/res.php", params={"key": API_KEY, "action": "get", "id": task_id})

    if res.text == "CAPCHA_NOT_READY": time.sleep(5); continue

    token = res.text.split("|")[1]; break

# inject token into g-recaptcha-response, submit the form

For v3 the same flow returns a token, but v3 returns a score driven by the session's reputation, not a puzzle — a separate rabbit hole; the cost model is the same either way.

The takeaway

For reCAPTCHA, don't ask the headline per-1,000 rate — ask what your bill looks like at 10× your volume. Usage-based 10×'s with you; thread-based is roughly flat. Size threads to peak concurrency, run the math on your real volume, and pick the model that matches your curve.

What DataDome actually checks — and why your Cloudflare playbook doesn’t transfer

Bassem Shahin — Thu, 18 Jun 2026 13:54:13 +0000

What DataDome actually checks — and why your Cloudflare playbook doesn’t transfer

You’ve got your Cloudflare setup dialed in — clean residential IPs, a real browser, a solver for the Turnstile widget — and then you hit a site that blocks you anyway, with a challenge that looks nothing like Cloudflare’s. Odds are it’s DataDome, and the reason your playbook stops working is that DataDome isn’t primarily a captcha. It’s a request-analysis and device-fingerprinting engine that sometimes shows a captcha. Treat it like Cloudflare and you’ll spin.

Here's how to recognize it, what it's really doing, and how to approach it honestly.

How to know it’s DataDome (not Cloudflare)

Read the response — the markers are distinct:

import requests

r = requests.get(url, headers=headers)
print(r.status_code) # often 403
print("datadome" in r.headers.get("set-cookie", "").lower()) # a `datadome` cookie
print(r.headers.get("x-datadome") or r.headers.get("x-dd-b")) # DataDome response headers
print("captcha-delivery.com" in r.text) # DataDome's challenge/captcha host
print('"dd"' in r.text) # a {"dd": {...}} JSON block in the 403 body

A datadome cookie, an x-datadome header, references to captcha-delivery.com / ct.captcha-delivery.com, or a {"dd": {...}} JSON block in a 403 → that’s DataDome.
Cloudflare’s tells are different: cf-mitigated, cdn-cgi/challenge-platform, cf_clearance. If you see those, it’s Cloudflare, and a different guide applies.

Getting the vendor right is the whole first step, because the fix is not the same.

Why it’s harder than “solve the captcha”

DataDome decides whether to even show a captcha based on a risk score it builds from:

Request fingerprint — TLS/JA3, HTTP/2 settings, header order. A raw client (or an obvious headless browser) scores badly before any challenge.
Device signals — a heavy client-side JS payload reads canvas/WebGL/fonts/timing/sensors; inconsistencies (a “desktop Chrome” with mobile-ish signals, or a timezone that disagrees with the IP) flag instantly.
Behavior — mouse movement, timing, navigation patterns.

So the captcha is the last gate, not the first. This is why people who “solve the DataDome captcha” still get blocked on the next request: the captcha token doesn’t fix a fingerprint that already looks automated. The defense is mostly upstream of the challenge.

How to handle it

Confirm it’s DataDome first (above) — don’t apply Cloudflare clearance logic to it.
Look for a way around the wall. Often the cheapest win: check whether the site exposes the same data via an official API or a backing JSON endpoint the page itself calls (devtools → Network → XHR). That can skip DataDome entirely.
If you must go through the front, fix the layers in order:
- IP — residential/mobile, geo-matched to your profile. Datacenter IPs score poorly with DataDome.
- Fingerprint — a real or patched-stealth browser whose values are internally consistent (and consistent with the IP’s geo). DataDome is stricter than Cloudflare on automation tells, so default Selenium/Playwright usually won’t survive.
- Behavior — human-ish timing and interaction, not machine-perfect.
The interactive captcha, when it appears (DataDome’s image/slider), is solvable like other image/interactive captchas — but only after the fingerprint/behavior look legitimate; otherwise a solved challenge just bounces on the next request. And the datadome cookie you earn is bound to the IP + UA + fingerprint that earned it (much like cf_clearance), so pin the session and don’t rotate mid-flow.

The honest summary: DataDome is a fingerprint/behavior problem with a captcha on top, not a captcha problem. Spend your effort on the IP + fingerprint + behavior stack; the challenge is the easy 20%.

TL;DR

Identify by the response: datadome cookie / x-datadome header / captcha-delivery.com / {"dd":...} 403 → DataDome (not Cloudflare).
It scores fingerprint + device + behavior before showing a captcha, so a solved challenge alone won’t save a bad fingerprint.
Order of fixes: residential geo-matched IP → internally-consistent real/stealth browser → human-ish behavior → (only then) the interactive challenge.
Pin the session — the datadome cookie is bound to IP+UA+fingerprint.

For the everyday captcha types you hit alongside this — reCAPTCHA v2/v3, Cloudflare Turnstile, GeeTest, image — CaptchaAI is 2Captcha-API-compatible, so an existing client is mostly a base-URL change, and the trial is free (3 days, no card).

Managed vs interactive Cloudflare challenge: how to tell, and why it changes your fix

Bassem Shahin — Thu, 18 Jun 2026 13:53:15 +0000

Managed vs interactive Cloudflare challenge: how to tell, and why it changes your fix

You send a request, Cloudflare blocks it, and you reach for “a Turnstile solver.” But half the time that’s the wrong tool — because what stopped you wasn’t a Turnstile widget at all, it was a managed challenge. They look similar from the outside and get lumped together as “Cloudflare captcha,” but they’re different mechanisms that need opposite handling. Picking the wrong one is why people burn hours (and solver credits) getting nowhere.

Here's how to tell which one you hit, straight from the response, and what each actually needs.

The two things people conflate

Interactive Turnstile widget. An embedded cf-turnstile widget sitting on an otherwise-normal page — usually a login or signup form. The page loads fine; the widget produces a token (cf-turnstile-response) that you submit with the form. The site verifies that token server-side.

Managed challenge. Cloudflare’s full-page interstitial — the “Checking your browser before you access…” screen — that gates the entire page before any real content loads. It runs a JavaScript challenge, scores the browser, and on success issues a cf_clearance cookie that lets subsequent requests through.

The confusion is understandable: a managed challenge can itself render a Turnstile widget as part of the interstitial. But the unit of work is completely different — a standalone widget gives you a token to submit; a managed challenge gives you a clearance cookie to carry.

How to tell them apart (from the response)

Don't guess from the screenshot — read what comes back.

import requests

r = requests.get(url, headers=headers)
print(r.status_code)
print(r.headers.get("cf-mitigated")) # "challenge" => managed challenge layer
print("cf-turnstile" in r.text) # a widget present in the DOM
print("challenge-platform" in r.text) # CF interstitial script => managed

Interactive widget: the page returns 200 with real content, and the HTML contains a cf-turnstile element with a sitekey. The captcha is part of a form, not the whole page.
Managed challenge: the response is the interstitial itself — typically 403/503, a cf-mitigated: challenge header, a body containing cdn-cgi/challenge-platform scripts, and no real page content. You never reach the actual HTML until you clear it.
Neither (rule this out first): a flat 403 carrying a Cloudflare error code like 1020 (firewall rule) or 1006/1007 (IP ban) is a WAF/IP decision — no token or clearance fixes that; you need a different egress IP or to stop tripping the rule.

Why it changes your fix

Interactive widget → token flow. Read the sitekey off the rendered widget + the page URL, get a token, inject it into the response field, and submit immediately (tokens are single-use and short-lived). You do not need a full browser session for the rest — just a valid token at submit time.

import requests, time

API_KEY, SITEKEY, PAGEURL = "YOUR_API_KEY", "0x4AAAAA...", "https://target.example/login"
rid = requests.post("https://ocr.captchaai.com/in.php", data={
    "key": API_KEY, "method": "turnstile",
    "sitekey": SITEKEY, "pageurl": PAGEURL, "json": 1,
}).json()["request"]
token = None
for _ in range(40):
    time.sleep(3)
    res = requests.get("https://ocr.captchaai.com/res.php", params={
        "key": API_KEY, "action": "get", "id": rid, "json": 1}).json()
    if res["status"] == 1:
        token = res["request"]; break
# submit token in cf-turnstile-response immediately

Managed challenge → clearance flow. A bare token is not enough. You need to actually pass the interstitial — in a real browser or a solver that runs the JS challenge — to mint cf_clearance, then reuse that cookie with the same IP + User-Agent + TLS fingerprint that earned it. Change any of those and Cloudflare re-challenges. So the pattern is: mint clearance once, pin the session (one sticky IP, one UA, a browser-matching TLS fingerprint like curl_cffi's impersonate), and re-mint when you see cf-mitigated: challenge again rather than replaying a dead cookie.

The expensive mistake is mixing them up:

Trying to “get a Turnstile token” for a managed challenge — there’s often no standalone widget token to fetch; you needed clearance.
Spinning up a full browser + clearance handling for a standalone widget — overkill; a token would have done it.

So the first move on any Cloudflare block is the 30-second classification above. It tells you whether you’re in token-land or clearance-land, and everything downstream depends on that.

TL;DR

Read the response first: cf-mitigated header + challenge-platform in body + no real content → managed challenge. A cf-turnstile sitekey on an otherwise-loaded page → interactive widget. 1006/1007/1020 → IP/WAF, not solvable with a token.
Interactive widget → solve sitekey+pageurl, inject token, submit immediately (single-use, short TTL).
Managed challenge → mint cf_clearance via a real browser/solver, pin IP+UA+TLS, re-mint on re-challenge.
Classify before you reach for a tool — the wrong path is why “Cloudflare won’t solve” turns into a lost afternoon.

If you want to test either path against your own target, CaptchaAI handles both (Turnstile tokens and the full managed-challenge clearance flow) and is 2Captcha-API-compatible, so an existing client is mostly a base-URL change — the trial is free (3 days, no card).

Cloudflare cf_clearance: why it expires and how to stop the re-challenge loop

Bassem Shahin — Tue, 16 Jun 2026 20:58:13 +0000

Cloudflare cf_clearance: why it expires and how to stop the re-challenge loop

You solve the Cloudflare challenge, get a cf_clearance cookie, make your next request — and Cloudflare throws you straight back to the challenge. You solve it again, same thing. The scraper is technically "working," it's just stuck in a loop, burning a solve on every request and never getting to the actual page.

This is one of the most common Cloudflare problems, and it's almost never the challenge itself. It's how cf_clearance is issued and what it's tied to. Once you understand that, the loop has a clean fix.

What cf_clearance actually is

When you pass a Cloudflare challenge (managed challenge, JS challenge, or interactive Turnstile), Cloudflare issues a cf_clearance cookie. That cookie is your proof of passage — present it on subsequent requests and Cloudflare lets you through without re-challenging.

The catch is that cf_clearance is not a portable token you can reuse anywhere. It carries two constraints that cause the loop:

1. It has a TTL

cf_clearance expires. The window varies by site configuration (often tens of minutes, sometimes shorter under stricter settings or "Under Attack" mode). When it expires, the next request gets challenged again — expected behavior. The bug is when your code keeps replaying an expired cookie instead of noticing it's dead and minting a fresh one.

2. It's bound to your IP + User-Agent + TLS fingerprint

This is the one that traps people. Cloudflare binds the clearance to the exact context that solved the challenge:

the IP that passed it,
the User-Agent string presented, and
the TLS/JA3 fingerprint of the client.

Change any of those between getting the cookie and using it, and Cloudflare treats the cookie as invalid and re-challenges. That's why these patterns loop forever:

Rotating proxies mid-session — you solve on IP A, your next request goes out IP B, cookie rejected.
Solving in a real browser, then submitting from requests — the browser's TLS fingerprint and UA don't match your HTTP client, so the cookie you carefully obtained is dead on the first reuse.
Spoofing a UA that doesn't match the fingerprint — claiming Chrome while sending a Python-requests JA3 is itself a mismatch.

How to confirm it's the loop and not something else

Before fixing, log what you're actually getting back:

import requests

r = requests.get(url, headers=headers, cookies={"cf_clearance": clearance})
print(r.status_code)
print(r.headers.get("cf-mitigated")) # "challenge" => you got re-challenged
print("cf_clearance" in r.cookies) # did this response set a NEW one?

cf-mitigated: challenge (or a challenge-page body) → you're in the re-challenge loop; the cookie was rejected.
A flat 403 with a Cloudflare 1006/1007 error code → that's an IP ban, not a clearance problem; no cookie fixes it (you need a different egress IP).
A clean 200 → you're through; the cookie is valid for now.

The fix

The loop breaks when you stop reusing a stale/mismatched cookie and instead evict-and-re-mint on the challenge signal, with a pinned context:

Pin one IP + one UA + one TLS fingerprint per session. Don't rotate the proxy mid-session. If you're submitting from Python, send a browser-matching TLS fingerprint (e.g. curl_cffi with impersonate) and the same UA you solved with — not the default requests fingerprint.
Detect re-challenge by the response, not a timer. Cloudflare can invalidate early, so don't trust a fixed "valid for N minutes" assumption. When you see cf-mitigated: challenge, treat the stored clearance as dead, evict it, and re-mint.
Re-mint with the same context that will reuse it. Whatever solves the challenge (a real browser or a solver) must produce a cookie usable by the same IP+UA+fingerprint that makes the real requests.
Optionally refresh proactively just before the known TTL to avoid a user-facing stall.

A minimal session loop that respects all of this:

import curl_cffi.requests as cc

session = cc.Session(impersonate="chrome") # browser-matching TLS fingerprint
UA = "Mozilla/5.0 (Windows NT 10.0; Win64; x64) ... Chrome/124.0 Safari/537.36"
session.headers["User-Agent"] = UA
PROXY = "http://user:pass@residential-ip:port" # one sticky IP for the session
session.proxies = {"http": PROXY, "https": PROXY}

def get(url, clearance):
    r = session.get(url, cookies={"cf_clearance": clearance} if clearance else {})
    if r.headers.get("cf-mitigated") == "challenge" or "challenge-platform" in r.text:
        clearance = mint_clearance(url, UA, PROXY) # re-mint with the SAME UA+IP
        r = session.get(url, cookies={"cf_clearance": clearance})
    return r, clearance

The point isn't the exact library — it's that the cookie, the UA, the IP, and the fingerprint all stay consistent, and a challenge response triggers a re-mint instead of another doomed retry.

If you offload the challenge to a solving service, the same rule applies: it has to mint the clearance against the IP+UA you'll reuse, or hand back a token you submit immediately in a matched context. CaptchaAI handles the Cloudflare challenge flow this way and is 2Captcha-API-compatible, so an existing client is mostly a base-URL change — and if you want to test it against your own target, the trial is free (3 days, no card).

TL;DR checklist

[ ] One IP + one UA + one TLS fingerprint, pinned for the whole session
[ ] Don't rotate the proxy mid-session
[ ] Submit with a browser-matching TLS fingerprint (not raw requests) if you solved in a browser
[ ] Detect re-challenge via cf-mitigated / challenge body, evict + re-mint — don't replay a dead cookie
[ ] Rule out a 1006/1007 IP ban first (different problem, needs a new IP)

Get those right and the loop turns into a single solve followed by clean 200s — which is how it's supposed to behave.

Cloudflare Turnstile in Playwright: Why Your Tests Stall and How to Solve It in 8 Lines

Bassem Shahin — Wed, 03 Jun 2026 21:38:36 +0000

Cloudflare Turnstile in Playwright: Why Your Tests Stall and How to Solve It in 8 Lines

If you're running Playwright or Selenium against any site behind Cloudflare, you've already met Turnstile. It's the new "managed challenge" widget Cloudflare started shipping in 2023, and it now appears in front of login flows, contact forms, signup pages, and increasingly the entire site root.

Here's the part most teams miss: Turnstile doesn't always show a checkbox. A lot of the time it just sits invisible, runs its scoring loop, and either issues a token silently or stalls forever. Your test doesn't crash. It just times out at the next page.click("button[type=submit]"). The CI log says "element not interactable." Nobody knows why.

I work on CaptchaAI. I'm going to show you exactly what's happening, then drop in 8 lines that fix it.

The real scenario

You have a Playwright suite that runs every PR. One day a test starts failing on the signup flow. You re-run it. It fails again. Locally on your laptop it passes. On CI it doesn't.

What's actually happening: Cloudflare flagged your CI runner's IP block (GitHub Actions, GitLab runners, Hetzner, OVH, DO — all of them are on Cloudflare's "elevated risk" list). Turnstile decides to switch from invisible mode to "managed challenge" mode. Now there's a widget in the DOM that needs a real token before the form submit will accept.

Your test never interacted with the widget because last week it didn't exist.

Why retries don't help

The instinct is to add a retry: 2 and move on. Don't. Cloudflare's scoring is per-IP-per-fingerprint, and each retry from the same runner makes the next challenge harder, not easier. After ~3 attempts you'll get full block pages instead of the widget.

The right move is to solve the widget once, inject the token, and submit normally — exactly what a human user does, just faster.

How Turnstile actually issues a token

The widget renders an iframe pointing at challenges.cloudflare.com. Inside the iframe it runs a fingerprint/behavior scoring loop for 1–4 seconds. When it's satisfied, it calls back into the parent page via a hidden <input name="cf-turnstile-response"> and fills the value attribute with a JWT-shaped token. That token is what the backend validates against Cloudflare's siteverify endpoint.

To solve Turnstile programmatically you need three things from the page:

The sitekey — visible in the page source as data-sitekey="0x4AAA..."
The page URL Turnstile was loaded on (Cloudflare validates this)
A solver service that returns a valid token for that pair

Then you inject the token into the hidden input and trigger the form submit. That's it.

Code

Here's a Playwright + Python integration. Endpoint and key:

Submit: https://ocr.captchaai.com/in.php
Poll: https://ocr.captchaai.com/res.php
API key placeholder: YOUR_API_KEY (get one at https://captchaai.com/trial — 3 days, 5 threads, no card).

import time, requests
from playwright.sync_api import sync_playwright

API_KEY = "YOUR_API_KEY"
TARGET_URL = "https://example.com/signup"

def solve_turnstile(sitekey: str, page_url: str) -> str:
    # 1. submit the task
    r = requests.post(
        "https://ocr.captchaai.com/in.php",
        data={
            "key": API_KEY,
            "method": "turnstile",
            "sitekey": sitekey,
            "pageurl": page_url,
            "json": 1,
        },
        timeout=20,
    ).json()
    if r.get("status") != 1:
        raise RuntimeError(f"submit failed: {r}")
    task_id = r["request"]

    # 2. poll for the token (typical solve: 8-20s)
    for _ in range(30):
        time.sleep(3)
        rr = requests.get(
            "https://ocr.captchaai.com/res.php",
            params={"key": API_KEY, "action": "get", "id": task_id, "json": 1},
            timeout=20,
        ).json()
        if rr.get("status") == 1:
            return rr["request"]  # the cf-turnstile-response token
        if rr.get("request") != "CAPCHA_NOT_READY":
            raise RuntimeError(f"solve failed: {rr}")
    raise TimeoutError("turnstile solve timed out")

with sync_playwright() as p:
    browser = p.chromium.launch()
    page = browser.new_page()
    page.goto(TARGET_URL)

    sitekey = page.locator("[data-sitekey]").first.get_attribute("data-sitekey")
    token = solve_turnstile(sitekey, TARGET_URL)

    # inject the token where Cloudflare expects it
    page.evaluate(
        "(t) => { document.querySelector('[name=cf-turnstile-response]').value = t }",
        token,
    )

    page.click("button[type=submit]")
    page.wait_for_url("**/welcome", timeout=15000)
    browser.close()

Same flow in Node.js with Playwright:

const { chromium } = require('playwright');

const API_KEY = 'YOUR_API_KEY';
const TARGET_URL = 'https://example.com/signup';

async function solveTurnstile(sitekey, pageUrl) {
  const submit = await fetch('https://ocr.captchaai.com/in.php', {
    method: 'POST',
    headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
    body: new URLSearchParams({
      key: API_KEY, method: 'turnstile',
      sitekey, pageurl: pageUrl, json: '1',
    }),
  }).then(r => r.json());
  if (submit.status !== 1) throw new Error('submit failed: ' + JSON.stringify(submit));
  const id = submit.request;

  for (let i = 0; i < 30; i++) {
    await new Promise(r => setTimeout(r, 3000));
    const poll = await fetch(
      `https://ocr.captchaai.com/res.php?key=${API_KEY}&action=get&id=${id}&json=1`,
    ).then(r => r.json());
    if (poll.status === 1) return poll.request;
    if (poll.request !== 'CAPCHA_NOT_READY') throw new Error(JSON.stringify(poll));
  }
  throw new Error('turnstile solve timed out');
}

(async () => {
  const browser = await chromium.launch();
  const page = await browser.newPage();
  await page.goto(TARGET_URL);

  const sitekey = await page.locator('[data-sitekey]').first().getAttribute('data-sitekey');
  const token = await solveTurnstile(sitekey, TARGET_URL);

  await page.evaluate(
    (t) => { document.querySelector('[name=cf-turnstile-response]').value = t; },
    token,
  );

  await page.click('button[type=submit]');
  await page.waitForURL('**/welcome', { timeout: 15000 });
  await browser.close();
})();

Expected output: the form submits, you land on /welcome, your test passes. Typical end-to-end overhead is 8–20 seconds for the solve.

Troubleshooting

A few real gotchas I've watched teams hit:

Wrong sitekey. If the page lazy-loads Turnstile (some React/Next sites do this), [data-sitekey] won't be in the DOM at page.goto. Wait for it: page.wait_for_selector('[data-sitekey]', timeout=10000).
Multiple Turnstile widgets. Login + reset-password + signup pages can all render the widget. Use a more specific selector (parent form + [data-sitekey]) so you don't solve the wrong one.
Token expired. Turnstile tokens are valid for ~300 seconds. If your test does a long DB seed step between solving and submitting, re-solve right before the click.
Site uses Turnstile in invisible mode. Look for data-size="invisible". The flow is identical — you still inject the token into the hidden input. The only difference is there's no widget UI rendered at all.
Backend uses a non-default secret. That's a Cloudflare configuration on the site owner's side; the token is still valid, your code is fine. If the backend rejects, the failure is at their siteverify step, not yours.

How this fits into a real CI pipeline

What I do in my own setup:

Run Playwright suites against a staging environment that's also behind Turnstile (don't whitelist your CI IPs at Cloudflare — that just hides the bug from yourself).
Set the solver as a thin module: one solve_turnstile function imported across every test that needs it.
Keep concurrency aligned with your thread allocation. If your plan gives you 5 threads and you run 12 parallel Playwright workers, 7 of them will queue. The BASIC plan ($15/mo) gives 5 threads with unlimited solves — fine for one repo. For monorepos with many parallel suites, STANDARD (15 threads, $30/mo, or $27 on /lp/new-year-deals) is the realistic floor.
Add a single retry on solver timeout — but not on Cloudflare block. The two failure modes need different handling.

Pricing for context (current as of 2026-06-02): unlimited solves on every plan, you pay only for thread concurrency. Trial is at https://captchaai.com/trial (3 days, 5 threads, no card). If you want a discount, https://captchaai.com/lp/new-year-deals has up to 17% off on STANDARD through ENTERPRISE.

What to do next

If you have a flaky test that times out at form submit on a Cloudflare-fronted page: drop the 8-line solver above into a helper, swap the sitekey lookup, and run it from a clean CI runner.

— Bassem

(disclosure: CaptchaAI maintainer)