DEV Community: Peak Fo

Why your scraper gets a 403 on Cloudflare Turnstile (and the token-injection fix)

Peak Fo — Mon, 07 Sep 2026 20:44:01 +0000

Your scraper works fine against the site's HTML, then one day every request comes back 403 — or the Turnstile widget just spins forever and never returns a token. Same code, same proxies, nothing changed on your end. Here's what's actually going on and the approach I've landed on after fighting it across a few dozen targets.

Two things get you blocked, not one

Cloudflare Turnstile scores the browser, and separately Cloudflare scores the connection. A 403 usually means you failed one of these:

Fingerprint. Turnstile runs JavaScript that pokes at the browser — canvas, WebGL, timing, the shape of your navigator object, whether events look human. A plain requests or httpx client runs none of that JS, so there's nothing to score and the challenge never clears. Headless Chrome runs the JS but leaks automation signals unless you go out of your way to hide them.
IP reputation. This is the one people miss. Cloudflare keeps lists of datacenter ranges. If you're coming from AWS, GCP, Hetzner, OVH, or a cheap datacenter proxy, you can have a perfect fingerprint and still get thrown into an endless challenge, because the IP is the tell.

A stealth browser can fix the first problem. It cannot fix the second. That's why people burn a weekend on undetected-chromedriver tweaks and still get walls of 403s — they solved fingerprinting and left the IP problem untouched.

The token is separate from your request

The thing that unlocks a clean fix: the widget produces a token — cf-turnstile-response — and on most deployments that token is validated server-side against the sitekey and the hostname, not against the IP that produced it. The site's backend calls Cloudflare's siteverify with the token and gets back pass/fail.

So you don't have to make your scraper's browser pass the challenge. You need a valid token for that sitekey and hostname, produced by something that can run the JS from a residential-looking IP, and then you attach it to your own request.

Getting the sitekey

It's sitting in the page. Look for data-sitekey on the Turnstile div, or a render() call in the JS:

import re
import requests

target = "https://example.com/login"
html = requests.get(target, timeout=20).text

m = re.search(r'data-sitekey=["\']([^"\']+)["\']', html)
sitekey = m.group(1) if m else None
print(sitekey)  # e.g. 0x4AAAAAAA...

If it's not in the initial HTML it's injected by JS — open DevTools, filter network for turnstile, and you'll see the sitekey in the challenges.cloudflare.com request.

Producing a token

Two honest options.

Run a real browser yourself. Playwright or Selenium with a genuine profile, pointed through a residential proxy, loading the page and reading the token out of the DOM after the widget resolves:

# token = page.locator("[name=cf-turnstile-response]").input_value()

This works when your fingerprint is clean and your IP is residential. It's the cheapest per-token if you already own good proxies and don't mind babysitting browser instances. It's slow (a full browser per solve) and it breaks whenever Cloudflare ships a new challenge variant, which is often.

Call a solving API. You hand it the URL and sitekey; it runs the browser farm on residential IPs and hands back a token. You keep your own scraper as a plain HTTP client. This is what I reach for when I care more about throughput than about owning the whole stack.

import requests

API_KEY = "pk_your_api_key"
TARGET  = "https://example.com/login"
SITEKEY = "0x4AAAAAAA..."

# 1) get a token — comes back in ~1s
resp = requests.post(
    "https://api.peak.fo/solve",
    headers={"X-API-Key": API_KEY},
    json={
        "task_type": "TurnstileTaskProxyLess",
        "url": TARGET,
        "sitekey": SITEKEY,
    },
    timeout=60,
).json()

if not resp.get("success"):
    raise RuntimeError(f"solve failed: {resp.get('error')}")

token = resp["data"]["token"]

# 2) attach the token to your real request, before it expires
r = requests.post(TARGET, data={
    "email": "you@example.com",
    "password": "...",
    "cf-turnstile-response": token,
})
print(r.status_code)

If the target binds the token to the solving IP (some do), pass a proxy field so the token is minted through the same residential IP you'll submit from.

Disclosure: I work on Peak, the API in that second snippet, so take the mention with that in mind. The API shape is close to interchangeable across providers — the request keys differ but the flow (POST url+sitekey, poll or await, get token) is the same. On price, most providers cluster around $1.20 to $1.45 per 1,000 Turnstile solves. Peak is $0.90 per 1,000 successful solves, dropping toward $0.35 at volume, and you're only billed for tokens that actually come back valid, with about 1,000 free solves to test first. Try whichever; the code above changes by one URL and a couple of JSON keys.

The four ways a valid token still fails

Once you have a token and it still doesn't work, it's almost always one of these:

Expired. Turnstile tokens live about 300 seconds. If you solve, then sit in a queue for five minutes, you're submitting a dead token. Solve right before you submit.
Reused. A token is single-use. The second request with the same cf-turnstile-response fails. One solve, one submit.
Wrong sitekey. You grabbed a sitekey from a different widget on the page, or from a cached older version. Re-pull it from the live page.
IP mismatch. The site's backend compares the solving IP to the submitting IP. If yours differ, solve through the same proxy you submit from.

When none of this helps

If the site validates far more than the token — device fingerprint tied to a session, behavioral signals across the whole flow, a cf_clearance cookie you also need — then a bare token won't carry you, and you're back to driving a full, well-fingerprinted browser through the entire session. Turnstile is one gate; some sites stack several. Fix the token gate first, because it's the one that's cleanly separable, then see what's left.

Originally published on the Peak blog.

What CAPTCHA solving actually costs (the line items nobody prints)

Peak Fo — Mon, 07 Sep 2026 20:36:58 +0000

The sticker price on a CAPTCHA solving service is almost never what you actually pay. Two services can both say "$1 per thousand" and cost you wildly different amounts by month's end, because the per-solve rate is one line in the bill. The rest hides in failed attempts, proxies, and a plan you didn't need.

Here's the honest breakdown of where the money goes, and a way to estimate your real cost before you commit.

Disclosure up front: I work on Peak, one of these services, so I'll use its numbers as the concrete example. The framework below is vendor-neutral — the point is how to read any pricing page, not which logo to pick.

The pricing models you'll see

Per-solve (pay as you go). You're quoted a rate per thousand solves. At Peak that's $0.90 per 1,000, so $0.0009 a solve — under a tenth of a cent. You add funds and draw them down. No monthly floor, no expiry.

Subscription / threads. Some services sell monthly plans priced by concurrent "threads" rather than solves. It can look cheap per solve at high volume, but you pay the full monthly rate whether you send one request or a million, and unused capacity is gone at month end.

Credits. A middle ground: you buy a bucket of credits, sometimes with an expiry date. Watch the expiry — credits you don't burn in time are just a quiet price increase.

The cost nobody prints: failed solves

This is the big one. Ask any service a single question: do I pay for failed solves?

If a service bills every attempt, your effective price is the quoted rate divided by your success rate. A "$1 per thousand" service that lands 80% of the time actually costs $1.25 per thousand successful tokens, and you feel it most on hard targets where failures cluster. Peak bills only on a successful solve, so the rate quoted is the rate paid — but the rule holds whoever you use: normalize everyone to cost-per-successful-solve, or you're comparing fiction.

The other cost: proxies

Most Cloudflare work needs a proxy, and on the challenges that bind to an IP — the interstitial "5-second" check and its cf_clearance cookie — it needs a sticky residential or mobile one. Proxy bandwidth is a separate bill from your solving spend, and for scraping-heavy jobs it can dwarf the solve cost. Budget for it explicitly instead of getting surprised.

A worked example

Say you need 50,000 successful Turnstile tokens this month. On a pay-per-solve service at $0.90 per 1,000 that bills only on success:

50,000 solves x $0.0009 = $45.00
failed solves:            billed nothing
total solving spend:      $45.00  (+ your proxy bandwidth)

Now the same 50,000 on a service that charges per attempt at the same headline rate, landing 85%:

to get 50,000 successes at 85%, you attempt ~58,800 times
58,800 x $0.0009 = $52.90 for the same 50,000 tokens

Same sticker price, roughly 18% more out of pocket, and the gap widens on harder targets. The number that matters is always cost per successful solve.

How to estimate your bill honestly

Volume. Successful solves per day, realistically — not your peak hour.
Billing basis. Per success or per attempt? If per attempt, divide the rate by your real success rate.
Proxy spend. Estimate bandwidth separately; it's often the larger line.
Floor and expiry. Any monthly minimum or credit expiry is part of the price.

Put those four numbers together and you have a budget instead of a headline. If you want to test the per-success model against your own numbers, Peak gives roughly 1,000 free solves before you add funds — enough to measure your real success rate on your actual targets, which is the input every estimate above depends on.

Originally published on the Peak blog.

Bypassing Cloudflare Turnstile from Python without driving a browser

Peak Fo — Mon, 07 Sep 2026 20:36:22 +0000

You wrote a clean scraper, pointed it at the target, and Cloudflare Turnstile stopped it dead. Your requests call comes back with a challenge page instead of data, and retrying changes nothing. Here's why that happens and the exact code I use to get past it.

The short version: a plain HTTP client can't pass Turnstile because it can't run the JavaScript the widget uses to score the browser. So you stop fighting the widget. You get a valid cf-turnstile-response token from something that can run that JS, and you submit the token with your request. That's the whole move, and it's a few lines.

Why requests alone can't do it

Turnstile isn't a puzzle you answer. It's a script that runs in a real browser and scores how browser-like the environment looks — canvas, timing, the shape of the navigator object, whether events look human. A bare requests or httpx call has no JavaScript engine, so it can't run that script at all, which means it can never produce the token the server wants. The server sees a missing or invalid cf-turnstile-response and rejects you.

This is also why time.sleep() and retry loops do nothing. Nothing about a retry changes what Cloudflare is scoring. You can loop for an hour; the client still can't run the JS.

What you actually need

Two moving parts.

The sitekey. It's the public Turnstile identifier sitting on the page. Look for data-sitekey on the Turnstile div, or a turnstile.render() call in the JS:

import re
import requests

target = "https://target.com/login"
html = requests.get(target, timeout=20).text
m = re.search(r'data-sitekey=["\']([^"\']+)["\']', html)
sitekey = m.group(1) if m else None
print(sitekey)  # e.g. 0x4AAAAAAA...

If it isn't in the initial HTML, it's injected by JS — open DevTools, filter the network tab for turnstile, and the sitekey shows up in the challenges.cloudflare.com request.

A token. You send the page URL, the sitekey, and a proxy to a solving service that runs a real browser on a residential IP, and you get a token back. Then you attach it to your own plain-HTTP request.

import requests

API_KEY = "pk_your_api_key"
TARGET  = "https://target.com/login"
SITEKEY = "0x4AAAAAAA..."
PROXY   = "http://user:pass@ip:port"

# 1) get a Turnstile token (comes back in about a second)
resp = requests.post(
    "https://api.peak.fo/solve",
    headers={"X-API-Key": API_KEY},
    json={
        "task_type": "turnstiletask",
        "url": TARGET,
        "sitekey": SITEKEY,
        "proxy": PROXY,
    },
    timeout=30,
).json()

if not resp.get("success"):
    raise RuntimeError(f"solve failed: {resp.get('error')}")

token = resp["data"]["token"]

# 2) submit the token with your request, before it expires (~300s)
r = requests.post(TARGET, data={
    "email": "you@example.com",
    "password": "...",
    "cf-turnstile-response": token,
})
print(r.status_code)

The value you get back is a normal cf-turnstile-response. The server can't tell it apart from one a browser produced, because it isn't different.

Disclosure: I work on Peak, the API in that snippet, so weigh the mention accordingly. The flow is close to identical across providers — POST url + sitekey, get a token, attach it — so the code changes by one URL and a couple of JSON keys if you use a different one. On price, Peak is $0.90 per 1,000 successful solves, dropping toward $0.35 at volume, and a miss costs nothing since you're only billed for tokens that come back valid. There's about 1,000 free solves to test with before you add funds.

The four ways a valid token still fails

When you have a token and it still bounces, it's almost always one of these:

Expired. Turnstile tokens last around 300 seconds and are single-use. Solve right before the request that needs it, not at the top of a long script.
Reused. Each submission needs a fresh token. The server redeems it once and the second request with the same value fails.
Wrong sitekey. A token solved against one sitekey won't validate on a different page. Re-pull it from the live page.
IP mismatch. Some deployments tie the token to the solving context. Solve through the same proxy you submit from, and pass the widget's action if it sets one.

When you need a browser instead

If your flow has to stay on the page and keep interacting after the challenge clears — a session cookie tied to the device, cf_clearance you also need, behavioral checks across the whole flow — then a bare token won't carry you, and driving a real browser with the token injected makes more sense. For a straight scrape where you just need to get past the gate and read data, the code above is all it takes.

Originally published on the Peak blog.