DEV Community: Bassem Shahin

Build vs buy: what running your own CAPTCHA-solving stack actually costs

Bassem Shahin — Sat, 11 Jul 2026 20:46:18 +0000

Build vs buy: what running your own CAPTCHA-solving stack actually costs

Every team that automates against the public web eventually hits the same fork: a scraper, a monitoring job, a QA suite, or an agent starts tripping CAPTCHAs, and someone asks "should we just build our own solver instead of paying a service?"

It's a fair question. The per-solve prices you see quoted (a dollar or three per 1,000) feel like something you could undercut with a weekend of code. Sometimes you can. But the sticker price of a solving service isn't really what you're comparing against — you're comparing against the fully-loaded cost of owning the problem forever. That second number is the one people underestimate, so let me lay it out honestly, including when building genuinely is the right call.

What "build your own" actually means

The naive version — "I'll just click the checkbox with Playwright" — works in a demo and falls over in production. A real self-hosted solving stack for the modern challenge types (reCAPTCHA v2/v3/Enterprise, Cloudflare Turnstile) is not one script. It's a system:

Challenge detection — reliably identifying which captcha is on a page and extracting its sitekey/parameters, across sites that change markup.
Token generation — a fleet of real (or hardened headless) browsers to actually produce valid tokens, because modern challenges are behavior- and signal-based, not image puzzles you can OCR.
Fingerprint + proxy management — reCAPTCHA v3 and Turnstile score the session (IP reputation, TLS/JA3, canvas, behavior), so you need residential/mobile egress and consistent fingerprints or your tokens come back low-score and useless.
Concurrency + queueing — running N solves in parallel without melting your box or getting the whole IP range flagged.
Retry/scoring logic — detecting a failed or low-score solve and retrying intelligently.
Monitoring — success-rate dashboards, alerting when a vendor changes something and your success rate quietly craters overnight.

None of that is exotic. All of it is real engineering, and — this is the part that bites — none of it is done once.

The hidden line item: the maintenance treadmill

Here's the cost that never shows up in the weekend-project estimate. The anti-bot vendors ship changes continuously. Google rotates reCAPTCHA internals; Cloudflare iterates Turnstile; challenge parameters and scoring shift. Every one of those can silently drop your homegrown success rate, and you find out from a downstream failure, not a changelog.

So "build your own" isn't a one-time build cost — it's a standing on-call commitment. Someone on your team now owns keeping a captcha solver alive, and that someone is pulled off your actual product every time the arms race moves.

Rough, honest math for a modest in-house stack:

Line item	Realistic cost
Initial build (detection + browser fleet + proxy glue + retries)	~1–3 engineer-months
Proxies (residential/mobile egress for valid scores)	ongoing $$ — often more than the solver would've cost
Infra (browser fleet, queue, monitoring)	ongoing $
Maintenance (the treadmill — reacting to vendor changes)	~0.2–0.5 of an engineer, indefinitely
Opportunity cost	whatever that engineer isn't building on your core product

At a loaded engineering cost, that maintenance fraction alone is often thousands of dollars a month — before proxies and infra. Compare that to a solving subscription that's typically tens to low-hundreds of dollars a month, and the "cheap" homegrown option frequently isn't.

When building actually wins

I'm not going to pretend buying always wins — it doesn't. Build when:

Solving is your product. If you're a proxy vendor, an anti-detect browser, or a scraping platform, captcha handling is core competency and differentiation. Own it.
You have genuinely unique requirements a general service can't meet — an obscure challenge type, an air-gapped environment, strict data-residency rules.
Extreme volume with margin pressure where, at your scale, an in-house team is demonstrably cheaper than any per-use or per-thread pricing — and you can staff the treadmill.

If one of those is you, building is rational. Budget for the maintenance, not just the build.

When buying wins (most teams)

For everyone else — teams where scraping/automation is a means, not the product — buying is almost always the right call, for one reason: you're offloading the treadmill, not just the code. A solving service absorbs every vendor change so your engineers stay on your roadmap. You wire up an API once and stop thinking about it.

And the integration is genuinely small. Most services expose the same three-step flow — submit the sitekey, poll for the token, inject it — and many are 2Captcha-API-compatible, so if you've ever used one you've basically used all of them:

import requests, time

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

# 1) submit the challenge (reCAPTCHA v2 shown; Turnstile = method="turnstile" + sitekey)
r = requests.get(f"{BASE}/in.php", params={
    "key": API_KEY,
    "method": "userrecaptcha",
    "googlekey": "SITE_KEY_FROM_THE_PAGE",
    "pageurl": "https://target.example/login",
})
task_id = r.text.split("|")[1]

# 2) poll for the token
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

# 3) inject the token into the page and submit

That's the whole integration surface. No browser fleet, no proxy sourcing for score quality, no 2 a.m. page when a vendor ships a change.

How to actually decide

Skip the per-1,000 sticker comparison. Ask three questions instead:

Is captcha solving part of what we sell? If yes, lean build. If no, lean buy.
Can we staff the maintenance treadmill indefinitely? Not the build — the upkeep. If that makes you wince, buy.
What's the fully-loaded in-house number — build + proxies + infra + that 0.2–0.5 engineer forever + opportunity cost — versus a subscription? Run that comparison, not the sticker one.

For most teams the honest answer is: your engineers are worth more on your product than on an arms race you'll never win outright. Buy the boring part, ship your actual thing.

If you want to sanity-check the buy side against your real volume, CaptchaAI's cost calculator lets you plug in your numbers, and there's a free trial if you want to compare success rates against your homegrown prototype before deciding. But whichever way you go, decide on the fully-loaded number — not the weekend-project fantasy.

reCAPTCHA v2 vs v3 vs Enterprise — how to tell which one you're fighting (and how to solve each)

Bassem Shahin — Tue, 30 Jun 2026 23:17:04 +0000

reCAPTCHA v2 vs v3 vs Enterprise — how to tell which one you're fighting

"reCAPTCHA is blocking me" is the start of a debugging session, not the end of one. There are four practical variants — v2 checkbox, v2 invisible, v3 score, and Enterprise — and they behave completely differently. They fail differently, they're solved differently, and the call you make to a solver isn't the same shape. So before you touch any code, the first job is identifying which one you're up against. The page tells you, if you know where to look.

How to tell which variant it is

Everything you need is in the page source and the script tags. Open devtools, look at the rendered widget and the api.js include.

v2 checkbox — the classic "I'm not a robot" box. In the DOM you'll see a

, and the page loads https://www.google.com/recaptcha/api.js. The sitekey starts with 6L. There's a visible checkbox; clicking it sometimes triggers an image grid ("select all bicycles").

v2 invisible — same api.js, same 6L... sitekey shape, but no visible checkbox. The widget is bound to a button or fired via grecaptcha.execute(), often with data-size="invisible". It only shows an image challenge if Google decides the session looks risky.

v3 score — there is no widget and no checkbox at all. The script include is https://www.google.com/recaptcha/api.js?render= — the ?render= parameter is the dead giveaway. The page calls grecaptcha.execute(sitekey, {action: 'login'}) and gets back a token plus a 0.0–1.0 score that the site's backend evaluates.

Enterprise — the script is https://www.google.com/recaptcha/enterprise.js?render=... (note enterprise.js, not api.js), and the JS calls live under grecaptcha.enterprise.*. Enterprise can run in a v2-style or v3-style mode, so identify it by the enterprise.js include first, then check widget vs. ?render=.

Quick reference for the script tell:

api.js + visible checkbox → v2 checkbox
api.js + data-size="invisible" / execute() → v2 invisible
api.js?render=KEY → v3
enterprise.js → Enterprise (then check widget vs. score mode)

What each means for automation

v2 checkbox is a puzzle problem — you need a token representing a solved challenge.
v2 invisible is mostly the same under the hood, except the challenge only surfaces when you look risky. Clean up IP/fingerprint and it often passes silently.
v3 is a reputation problem, not a puzzle. Nothing to click — you're scored on IP, fingerprint, behavior, and the action. A "fail" means you scored below the site's threshold.
Enterprise is the same two modes wearing a different SDK. The practical difference is the namespace and sometimes a required actionenterprise flag. It's the same v2/v3 mechanics with more backend signals on the site's side; your client job barely changes.

The most common mistake: grabbing a token for the wrong variant — a plain v2 token sent to a v3 endpoint, or v3 solved without the matching action. The token comes back fine, the form submits, and the site silently rejects it. Identifying correctly up front saves that whole loop.

The solve flow per variant

If your solving already speaks the 2Captcha-style API method=userrecaptcha, googlekey, pageurl), every variant is the same endpoint with a couple of parameters flipped. Submit to in.php, poll res.php, drop the token into g-recaptcha-response.

v2 checkbox / invisible: method=userrecaptcha, googlekey=, pageurl=. Invisible uses the exact same call.
v3: add version=v3 and action= (e.g. login). The action must match what the page passes to execute(). You can't request a score — the site's backend sets the minimum.
Enterprise: add enterprise=1 alongside the v2 or v3 parameters depending on the mode. Same googlekeypageurl; if score mode, still send action.

Here's the v3 case end to end; v2 is the same minus versionaction, Enterprise adds enterprise=1:


import requests, time

API_KEY  = "YOUR_API_KEY"

SITEKEY  = "6Lc..."                       # the data-sitekey / render key

PAGEURL  = "https://target.example/login"

# submit (v3 shown; drop version+action for v2, add enterprise=1 for Enterprise)

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

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

    "version": "v3", "actison": "login",

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

}).json()["request"]

# poll

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 (matching the action for v3)

TL;DR

Identify from the script include: api.js (v2), api.js?render= (v3), enterprise.js (Enterprise); then checkbox vs. invisible vs. score by the widget/flow.
v2 = puzzle/token, v3 = reputation/score, Enterprise = same two modes, different SDK + an enterprise flag.
Solve flow is one endpoint: userrecaptcha + googlekey + pageurl, with version=v3action for v3 and enterprise=1 for Enterprise.

CaptchaAI returns tokens for reCAPTCHA v2 (checkbox + invisible), v3 (with action), and Enterprise, and it's 2Captcha-API-compatible — so an existing client is mostly a base-URL change. The trial is free (3 days, no card).

Why your Cloudflare Turnstile token works in the browser but 403s from requests

Bassem Shahin — Sun, 28 Jun 2026 09:54:14 +0000

Why your Cloudflare Turnstile token works in the browser but 403s from requests

You solved the Turnstile widget. You can see the token in the page. You copy it into your script, POST the form from requests, and the server hands you back a 403 — or a JSON body with "success": false. The token clearly worked a second ago in the browser, so what changed?

Short answer: a Turnstile token is not a password you can carry around. It's a one-time, short-lived proof bound to a very specific context, and replaying it from a different context is exactly what it's designed to reject. Below is what that context is, how to tell which constraint you're hitting, and the fix for each.

The real scenario

You're automating a flow on a Cloudflare-protected site. There's a cf-turnstile widget on the form. You get a token one of two ways:

you render the page in a real browser (Playwright/Selenium) and read cf-turnstile-response, or
you hand the sitekey + page URL to a solving service and get a token back.

Either way, you then submit the form with a plain HTTP client requests, httpx, axios) and it fails. The frustrating part: it's intermittent-looking. The reason it feels random is that there are four separate constraints, and you're usually tripping a different one each time.

The four things a Turnstile token is bound to

1. It's single-use

Once Cloudflare validates a token server-side (the siteverify call your target makes), that token is spent. Submit twice, retry, or test it once by hand, and the second use returns false. You get a fresh one per submission.

2. It has a short TTL

Turnstile tokens expire fast — a few minutes. Solve early, do other work, submit later, and the token can be dead on arrival. The widget auto-refreshes in the browser precisely because tokens go stale; a script that grabs the token and sits on it loses that refresh.

3. It's bound to the sitekey and the page URL

Multiple widgets. Some pages embed more than one Turnstile (login + newsletter). Solving the wrong sitekey gives a token the server rejects.
Runtime-injected sitekeys. Many sites inject the sitekey with JS at render time, sometimes rotating it. If you scraped it from static HTML once, it may already be wrong. Read it off the rendered widget.

4. If it's a managed challenge, the browser gets re-checked on submit

This one bites people who "did everything right." A standalone widget issues a token you can submit from anywhere. But Cloudflare's managed challenge re-evaluates the request on submission: TLS/JA3 fingerprint, the cf_clearance cookie, IP reputation. A token minted in a real browser, then replayed from a raw HTTP client with a different fingerprint and no clearance cookie, fails that second check no matter how valid the token is.

How to tell which one you're hitting

Don't guess — read the response.


import requests

resp = requests.post(target_url, data=form, headers=headers)

print(resp.status_code)

print(resp.headers.get("cf-mitigated"))   # present => Cloudflare challenge layer

print(resp.text[:600])                     # body usually names the cause

JSON {"success": false, "error-codes": [...]} from the site's verify endpoint → it's the token (expired/reused/wrong sitekey). Codes are explicit: timeout-or-duplicate, invalid-input-response.
A 403 with a cf-mitigated header + challenge-page body → it's the fingerprint/clearance layer (#4), not the token.
A 403503 with a Cloudflare code like 1020 → a WAF/IP decision; no token solves that.

The fix

For a standalone widget (causes 1–3): solve against the exact sitekey from the rendered widget and the exact page URL; submit immediately (seconds, not minutes); solve once per submission, never reuse. Token flow with a 2Captcha-compatible API (so an existing 2Captcha client is a base-URL change):


import requests, time

API_KEY = "YOUR_API_KEY"

SITEKEY = "0x4AAAAA..."   # read from the rendered widget, not static HTML

PAGEURL = "https://target.example/login"

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

    "key": API_KEY, "method": "turnstile",

    "sitekey": SITEKEY, "pageurl": PAGEURL, "json": 1}).json()

task_id = r["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": task_id, "json": 1}).json()

    if res["status"] == 1:

        token = res["request"]; break

form["cf-turnstile-response"] = token   # submit RIGHT AWAY — single-use, short-lived

resp = requests.post(PAGEURL, data=form, headers=headers)

For a managed challenge (cause 4): a bare token isn't enough — carry the browser context it was minted in. Keep the cf_clearance cookie; pin the same IP, same User-Agent, and a browser-matching TLS fingerprint from minting through submission (e.g. curl_cffi with impersonate, or submit in the same browser context). Rotating the proxy or switching to a raw-client UA breaks it.

Rule of thumb: match the token to its sitekey+URL, submit before it ages, and keep the fingerprint that solved a managed challenge identical through submission.

Quick gut-check

[ ] Sitekey read from the rendered widget (handles injection / multiple widgets)
[ ] Page URL passed to the solve matches the page you submit to
[ ] Token submitted within seconds, used exactly once
[ ] Checked the response for cf-mitigated / Cloudflare codes (token-layer vs fingerprint-layer)
[ ] Managed challenge: same IP + UA + TLS fingerprint, clearance cookie carried through

Read the response first. Nine times out of ten it tells you whether you're fighting the token or the fingerprint — and those are very different fixes.

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)