DEV Community: Peak Fo

How to Scrape Cloudflare-Protected Sites Without Getting Blocked

Peak Fo — Fri, 09 Oct 2026 07:17:53 +0000

Cross-posted from blog.peak.fo. I work on Peak, a Cloudflare Turnstile/5-second-challenge solving API, so the code example below calls it — the proxy, header, and pacing advice stands regardless of which solver you use.

You write a scraper, it works on your machine, and the moment you point it at a Cloudflare site you get a wall: a challenge page, a 403, or an endless "checking your browser." Cloudflare sits in front of a huge share of the web now, so if you scrape at all, you'll meet it. Here's how to collect public data from Cloudflare-protected sites without tripping every alarm, and how to stay on the right side of the line while you do it.

First, the honest framing. This is about legitimate work: public data, price monitoring, research, testing your own properties. Respect the target's terms of service and its robots rules, keep your request rate reasonable, and don't hammer infrastructure you don't own. The techniques below reduce false-positive blocks on legitimate crawling; they aren't a license to abuse a service.

Why Cloudflare blocks you

Cloudflare stacks several defenses, and you can hit any of them. IP reputation comes first: a datacenter IP that thousands of scrapers already burned is suspect before you send a single header. Then there's the environment check, where JavaScript challenges like Turnstile and the 5-second interstitial look at whether a real browser is present. On top of that, rate and pattern analysis flags traffic that behaves like a script: too fast, too regular, no human rhythm.

Get blocked and it's usually one of those three, not some unbeatable magic. Fix them in order.

The playbook

1. Use good proxies, and keep the session sticky

This is the biggest lever. Residential and mobile IPs carry far better reputation than datacenter ranges, because they look like real users. Rotate them so you're not slamming a site from one address, but keep a session sticky when you need continuity: if you've earned a clearance cookie, the follow-up requests have to come from the same IP or Cloudflare throws the cookie out. Cheap datacenter proxies are a false economy here; they're where most "why am I blocked" stories start.

2. Send believable headers

A default Python or Node user-agent is a giveaway. Send a real browser user-agent, and make the rest of your headers consistent with it (accept-language, accept-encoding, the usual set). The point isn't to lie; it's to not stick out as an obviously scripted client when you're doing ordinary crawling.

3. Clear the challenges, then reuse what you get

When you hit an actual challenge, you have two things to handle. The Turnstile widget returns a token you submit with the form. The 5-second interstitial returns a cf_clearance cookie you reuse on later requests. Solve once, then reuse: don't re-challenge yourself on every request. With a solving API this is a single call that hands back the token or the cookie plus the matching user-agent.

import requests

# clear the 5s challenge once, keep the clearance for the session
sol = requests.post(
    "https://api.peak.fo/solve",
    headers={"X-API-Key": "pk_your_api_key"},
    json={"task_type": "cloudflare5stask", "url": "https://target.com/",
          "proxy": "http://user:pass@ip:port"},
    timeout=30,
).json()["data"]

s = requests.Session()
s.headers["User-Agent"] = sol["headers"]["user-agent"]
for k, v in sol["cookies"].items():
    s.cookies.set(k, v)
# now crawl with s, same proxy, at a human pace

4. Slow down and vary

Machine-perfect timing is a tell. Space requests out, add jitter, and don't crawl a thousand pages a minute from one session. Respect the rate the site can reasonably serve. Slower and steady beats fast and blocked, every time.

Browser or API for the challenge?

If your crawl needs to click through pages and read content that only renders after interaction, run a real browser and let it handle the challenge inline. If you just need the token or the cookie and then you're making plain HTTP requests, an API is lighter and scales without a browser per worker. Most large crawls end up using the API for the challenge and their own HTTP client for the actual fetching. We break the trade-off down in the Turnstile solving guide.

FAQ

How do I scrape a Cloudflare-protected site?
Use residential or mobile proxies with sticky sessions, send real browser headers, solve any Turnstile or 5-second challenge and reuse the token or cf_clearance cookie, and crawl at a human pace. Most blocks come down to a bad IP, a scripted-looking client, or too-fast requests.

Is scraping Cloudflare sites legal?
Scraping public data is generally fine, but it depends on the site's terms of service, its robots rules, and what you do with the data. Don't access private or account-gated content you're not authorized to, and respect rate limits. The tooling is neutral; the use is on you.

Why do I keep getting the 5-second challenge?
Usually because you're not reusing the cf_clearance cookie, or you're sending it from a different IP or user-agent than the one that earned it. Keep the session sticky and send the matching user-agent. See the cf_clearance guide.

Start free at peak.fo. Bring your own proxy, pay only for solves that land.

CAPTCHA Solving API vs Headless Browser: Which to Use

Peak Fo — Thu, 08 Oct 2026 07:24:38 +0000

Cross-posted from blog.peak.fo. I work on Peak, the solving API mentioned below.

Two teams hit the same Cloudflare wall. One spins up a fleet of headless Chrome instances with stealth plugins. The other sends an HTTP POST to a solving API and gets a token back. Both work. But by month three they're in very different places, and it's usually not the place they expected.

Here's the short version. Use a solving API when you need the token or the clearance cookie and nothing else. Use a headless browser when you need to stay on the page and interact with it after the challenge clears. Most scraping and automation jobs are the first kind, which is why the API route wins more often than people assume going in.

The real trade-off, dimension by dimension

	Solving API	Headless browser
What you get back	A token or `cf_clearance` cookie	A live browser you keep driving
Speed per solve	~1 to 1.5s on a typical target	Seconds, plus browser startup and page load
Cost model	Pay per successful solve	Your CPU, RAM, and proxy bandwidth, always
Maintenance	The vendor chases Cloudflare changes	You patch stealth every time detection shifts
Scale	Concurrency is just more requests	Each browser is hundreds of MB of RAM
Best when	You only need to get past the check	You need full JS state and page interaction

Where the headless browser genuinely wins

Don't let anyone tell you the browser is always the wrong answer. If your job is to log in, navigate three pages deep, click through a JavaScript-heavy flow, and read state that only exists in a live DOM, you need a browser anyway. Once you're paying for that browser, solving the challenge inside it can make sense, because the page context, cookies, and fingerprint are already consistent.

The catch is what it costs you to keep that browser undetected. Cloudflare's bot management reads canvas fingerprints, WebGL, timing, and dozens of other signals. Stealth patches drift out of date. You end up maintaining an anti-detection layer as a permanent side project, and every Cloudflare update is a fire drill.

Where the API wins

If all you actually need is the cf-turnstile-response token to submit with a form, or the cf_clearance cookie to reuse on requests, a browser is a lot of machinery for a small output. The API turns the whole thing into one call:

import requests

token = requests.post(
    "https://api.peak.fo/solve",
    headers={"X-API-Key": "pk_your_api_key"},
    json={
        "task_type": "turnstiletask",
        "url": "https://target.com/",
        "sitekey": "0x4AAAAAAAxxxxxxxx",
        "proxy": "http://user:pass@ip:port",
    },
    timeout=30,
).json()["data"]["token"]
# submit token with your request; done

No browser pool, no stealth plugins, no RAM ceiling on concurrency. When Cloudflare changes something, that's the vendor's problem to fix, not yours. And because Peak bills only on a successful solve, a failed attempt costs nothing, which quietly changes the math versus a browser that burns compute whether or not it gets through.

If you want the token explained end to end, read the cf-turnstile-response token, explained. For the cookie flow on the 5-second challenge, see the cf_clearance cookie.

A quick way to decide

Ask one question: after the challenge clears, do you still need the browser? If yes, keep the browser and solve inside it. If no, and you just need the token or cookie to make your own requests, the API is less code, less infrastructure, and less maintenance. Plenty of teams run both, a browser for the deep interactive flows and the API for the high-volume "just get me past the gate" work.

FAQ

Is a solving API faster than a headless browser?

For getting a token, usually yes, because you skip browser startup and page render. A Peak solve typically returns in about one to one and a half seconds. A browser has to launch, load the page, and let the widget run before you can read the field.

Which is cheaper at scale?

It depends on volume and what else you're doing. Browsers cost CPU, RAM, and proxy bandwidth continuously, including on failed attempts. A pay-per-solve API costs a fixed amount only when it succeeds. See how to choose a solving service to run your own numbers.

Can I use both?

Yes, and many teams do. Use the browser where you need live page interaction, and the API for high-volume token or cookie work. The Turnstile solving guide walks through both paths.

Skip the browser pool. Grab a key free at peak.fo. $0.90 per 1,000 successful Turnstile solves, down to $0.35 at volume, and failed solves aren't billed.

reCAPTCHA v3 Enterprise: How Score-Based Solving Works (and Why There's No Puzzle)

Peak Fo — Wed, 30 Sep 2026 07:25:33 +0000

Cross-posted from the Peak blog. I work on Peak, an API for solving Cloudflare Turnstile and the Cloudflare 5-second challenge.

There's no checkbox. No blurry traffic lights. You just submit a form and get quietly rejected, or dropped into a harder challenge, with no obvious CAPTCHA anywhere.

That's reCAPTCHA v3, and it's a different animal from anything with a puzzle. It doesn't ask you to prove you're human. It watches, scores you, and lets the site decide what to do with the number.

Understanding that score is the whole game, because you can't "solve" a v3 the way you solve a Turnstile widget. There's nothing to click. What you can do is understand what moves the score and what a solving service actually returns.

How reCAPTCHA v3 works

v3 runs invisibly on the page and, on an action you trigger (a submit, a login, a page view), produces a token carrying a score from 0.0 to 1.0. Higher means "looks human," lower means "looks like a bot." The site sends that token to Google's siteverify, gets the score back, and applies its own threshold. A common setup blocks below 0.5, waves through above, and sometimes steps borderline traffic up to a harder challenge.

The key difference from v2 or Turnstile: there is no pass/fail interaction. The token always issues. What varies is the number attached to it, and that number is computed from signals the site never shows you.

What Enterprise adds

reCAPTCHA Enterprise is the paid tier with more risk analysis behind the same idea. Instead of a bare score, it returns reason codes, richer signals, and tunable assessments the site can weigh however it likes. For you on the outside, it behaves like v3 but stricter and harder to fool, because there's more feeding the score than a single number.

Why "solving" v3 is really "scoring high"

Since the token always issues, getting one is trivial and useless; a token with a 0.1 score gets you blocked just the same. The real task is producing a token that scores high enough to clear the site's threshold. That depends on things a puzzle-solver can't brute force:

Browser reputation. A clean, consistent, real-looking browser environment scores better than a flagged headless one.
IP reputation. Residential and mobile IPs score higher than datacenter ranges Google associates with automation. This is exactly where residential vs datacenter proxies starts to matter.
Behavioral consistency. Actions that look like a real user's flow score better than a cold, mechanical hit on the endpoint.
Account and history signals. On Enterprise especially, prior behavior tied to the session feeds the assessment.

That's why raising a v3 score is closer to looking legitimate than to cracking a challenge. A high-score token comes from a request that genuinely resembles a trusted user.

Where Peak fits

Today Peak covers Cloudflare Turnstile and the Cloudflare 5-second challenge, the two we've built and verified end to end. reCAPTCHA v3 Enterprise support is on the near-term roadmap, and because it's a scoring problem rather than a puzzle problem, the same fundamentals we already lean on carry over: a trustworthy browser environment and a good IP through your proxy. When it lands it'll follow the same shape as the rest of the API, so the switch is a task type, not a rewrite.

Watch the Peak docs for the release, and if you're comparing what different challenges need, Turnstile vs reCAPTCHA vs hCaptcha lays out the landscape.

What you can do right now

If you're facing v3 today, the levers are the ones that lift the score: use residential or mobile IPs on strict targets, keep a clean and consistent browser environment, and don't hammer the endpoint in a way no human would. None of that is a magic token; all of it moves the number Google hands the site.

For the wider approach to staying unblocked, see scraping without getting blocked.

FAQ

Can you solve reCAPTCHA v3?

Not in the puzzle sense; there's nothing to click. v3 always issues a token, but with a score from 0.0 to 1.0. The goal is a token that scores high enough to clear the site's threshold, which comes from a legitimate-looking browser and IP rather than from cracking anything.

What is a good reCAPTCHA v3 score?

Sites set their own threshold; 0.5 is a common cutoff, with higher scores waved through and lower ones blocked or stepped up. Enterprise adds reason codes and richer signals on top of the score.

Does Peak support reCAPTCHA v3 Enterprise?

Not yet. Peak currently solves Cloudflare Turnstile and the 5-second challenge; v3 Enterprise is on the near-term roadmap. Watch the docs, or see pricing for what's live today.

Solving Cloudflare today, reCAPTCHA v3 soon. Grab a key free at peak.fo.

Residential vs Datacenter Proxies for Solving CAPTCHAs

Peak Fo — Thu, 24 Sep 2026 07:21:54 +0000

Cross-posted from blog.peak.fo. I work on Peak, a Cloudflare Turnstile/5-second-challenge solving API, so take the proxy recommendations below with that in mind — the underlying tradeoffs hold regardless of which solver you use.

Your solves work perfectly in testing. You ship to production, point it at real volume, and suddenly half of them fail. Nine times out of ten the code didn't change; the proxy did. The IP you solve through is part of what Cloudflare scores, and datacenter versus residential is the decision most people get wrong in one direction or the other.

Quick answer up front. Datacenter proxies are fine for a lot of Turnstile work and much cheaper. Residential (or mobile) proxies earn their cost on strict targets and anything that binds to your IP, like the cf_clearance cookie. Start cheap, escalate only where the data tells you to.

What actually differs

	Datacenter	Residential / mobile
Where the IP lives	A cloud or hosting provider	A real ISP or carrier subscriber
Cloudflare's default trust	Lower; flagged as hosting	Higher; looks like a real visitor
Cost	Cheap, often flat	Expensive, usually per GB
Speed	Fast, stable	Slower, more variable
Best for	High-volume, less strict targets	Strict sites, IP-bound clearance

Cloudflare keeps a reputation signal on IP ranges. Datacenter ranges are known to be datacenter, so they start from a lower baseline. That doesn't mean they fail; plenty of Turnstile targets issue tokens fine from datacenter IPs when the rest of the request looks right. It means the margin is thinner, so on a strict site a datacenter IP tips over into a challenge where a residential one sails through.

When datacenter is the right call

If you're pulling public data at volume from targets that aren't especially aggressive, datacenter proxies are the economical choice. They're fast, stable, and cheap enough that you can rotate widely. For a lot of Turnstile token work, that's all you need. Spending on residential here is burning money for reliability you already have.

When you need residential or mobile

Two situations flip the decision.

First, strict targets that challenge datacenter ranges on sight.

Second, and this is the one people miss, anything that binds to your IP. The Cloudflare 5-second challenge issues a cf_clearance cookie tied to the exact IP that earned it, so you need that IP to stay yours for the life of the session. A rotating datacenter pool breaks this instantly; the next request comes from a new IP and the clearance is void. The mechanics are in the cf_clearance cookie, explained.

Sticky vs rotating matters as much as the type

A residential proxy that rotates every request is useless for clearance work, and a sticky datacenter session can outperform rotating residential for a flow that needs IP continuity. Match the session to the job:

One-shot Turnstile token: rotating is fine; each solve stands alone.
cf_clearance reuse across many requests: sticky, so the IP holds.
A login or multi-step flow: sticky for the whole session so cookies and IP stay consistent.

Peak passes your proxy straight through on the proxy field, so you control the type and stickiness per request. Use a sticky residential proxy for 5-second clearance, a cheap datacenter one for high-volume token pulls, and pay for residential only where it changes the outcome.

A sensible default

Start every new target on datacenter. Watch the success rate. If it's clean, you just saved a fortune in bandwidth. If failures cluster, move that target to sticky residential and compare. Let the numbers pick, target by target, instead of paying the residential premium everywhere out of caution.

The broader anti-blocking playbook is in scraping Cloudflare-protected sites without getting blocked.

FAQ

Do I need residential proxies to solve Cloudflare Turnstile?
Not always. Many Turnstile targets issue tokens fine from datacenter IPs. Residential pays off on strict sites and on anything IP-bound like the cf_clearance cookie. Start datacenter and escalate where failures cluster.

Why does cf_clearance need a sticky proxy?
Cloudflare binds the clearance cookie to the IP that earned it. If your proxy rotates, the next request comes from a different IP and the cookie is rejected. A sticky session keeps the IP constant for the cookie's life.

Are datacenter proxies always worse?
No. They're cheaper, faster, and stable, and they work on many targets. They only lose on strict sites and IP-bound flows. Pick per target, not by blanket rule.

See pricing to start. Bring your own proxy, pay only for solves that land. Grab a key free at peak.fo.

Cloudflare Turnstile vs reCAPTCHA vs hCaptcha (2026): which should you use?

Peak Fo — Wed, 23 Sep 2026 07:26:03 +0000

Cross-posted from blog.peak.fo. I work on Peak, the Turnstile-solving API mentioned below.

Three products, one job: tell humans and bots apart without making real people hate your site. Cloudflare Turnstile, Google reCAPTCHA, and hCaptcha go about it differently, and the right pick depends on whether you're the one adding the widget or the one automating against it.

Quick verdict. Pick Turnstile if you want free, privacy-friendly, and low-friction and you can live in Cloudflare's ecosystem. Pick reCAPTCHA if you're deep in Google's stack and want the score-based v3 signals. Pick hCaptcha if you need enterprise features like EU-region processing or you want the publisher rewards angle. If you're on the automation side, the calculus flips, and I'll cover that below.

How each one decides you're human

reCAPTCHA v2 is the "click the checkbox, then maybe pick the buses" one. v3 dropped the puzzle entirely and returns a score from 0 to 1 that you act on server-side. hCaptcha looks a lot like reCAPTCHA v2 to a user (image grids), but it's a separate company with its own infrastructure, and it built a business around paying site owners for the labeling work.

Turnstile took the other road. Most of the time it shows nothing, or a checkbox that resolves on its own. It runs JavaScript to read the browser environment, leans on Cloudflare's network reputation for your IP, and hands back a token. No image labeling, no "select all crosswalks."

Side by side

	Cloudflare Turnstile	Google reCAPTCHA	hCaptcha
User experience	Usually invisible / self-ticking	v2 puzzles, v3 invisible score	Image grids (v2-like)
Cost to the site	Free at any scale	Free tier, paid Enterprise	Free tier, paid Enterprise; publisher rewards
Privacy	No third-party ad tracking	Ties into Google	More privacy-focused than Google
Requires an account	Cloudflare account	Google account	No account needed to embed
Signal style	Environment + IP reputation	Behavior + Google graph (v3 score)	Behavior + image challenge

For site owners the honest read is: Turnstile wins on price and friction, reCAPTCHA wins if you already live in Google's world, and hCaptcha wins on enterprise/region controls and the rewards program. None of them is a silver bullet against determined bots, because the token is only as strong as the environment and IP behind it.

From the automation side: which is hardest to solve?

This is where most comparison posts go quiet, so here's the practitioner view. For legitimate automation, scraping public data, or QA on your own forms, the three behave differently under a solver.

Turnstile is a token problem. You need a valid token for the sitekey from an IP Cloudflare doesn't flag. No image labeling in the loop, so it's fast to solve programmatically, usually about a second with a clean proxy. We wrote the full walkthrough in how to solve Cloudflare Turnstile.

reCAPTCHA v2 historically leaned on image recognition, so solving it meant either a machine-vision model or a human-in-the-loop. v3 is score-based, which makes it less about "solving a puzzle" and more about presenting a trustworthy session, which is a different and often harder engineering problem. reCAPTCHA v3 Enterprise raises that bar again, and it's the next challenge type Peak is bringing online.

hCaptcha sits closer to reCAPTCHA v2 in shape: image challenges that need vision or human solvers. Doable, but heavier per solve than a token-only widget like Turnstile.

So if you're choosing what to put on your site to slow bots, the ranking of "annoying to automate" isn't fixed; it depends on the attacker's tooling. If you're the one automating legitimately, Turnstile is typically the cleanest to handle because it's token-based, and a solving API returns that token in about a second at a tenth of a cent, billed only when it lands.

Which should you actually use?

If you run a site and you're already on Cloudflare, Turnstile is the easy default: free, quiet, and privacy-clean. If your analytics and ads already run through Google and you want v3 scoring baked into risk decisions, reCAPTCHA fits. If you have a compliance need for EU processing or you want to earn from the labeling, hCaptcha earns its slot. There isn't a universally "best" one, and anyone who tells you otherwise is selling something.

FAQ

Is Turnstile better than reCAPTCHA?

For most sites, Turnstile is friendlier: free at any scale, usually invisible, and it doesn't hand data to an ad network. reCAPTCHA's edge is v3's score signal and tight Google integration. Different strengths, not a clean win either way.

Which CAPTCHA is easiest to solve for automation?

Token-based challenges like Turnstile are typically the cleanest to handle programmatically, because there's no image labeling in the loop. Image-grid challenges (reCAPTCHA v2, hCaptcha) need vision models or human solvers and cost more per solve.

Does Peak support all three?

Peak solves Cloudflare Turnstile and the Cloudflare 5-second challenge today, with reCAPTCHA v3 Enterprise coming next. See pricing and the docs.

Need to clear Turnstile at volume? Start free at peak.fo, or read the Turnstile solving guide.

cf-turnstile-response: the token explained, and how to get one

Peak Fo — Tue, 22 Sep 2026 07:15:05 +0000

Cross-posted from blog.peak.fo. I work on Peak, a pay-per-solve Turnstile API — disclosing that up front.

You open the page source, find a hidden input called cf-turnstile-response, and it's empty. Submit the form without filling it and the server bounces you. That one field is the whole handshake between Cloudflare Turnstile and the site behind it, and once you understand what goes in it, solving Turnstile stops feeling like magic.

cf-turnstile-response is the token Cloudflare Turnstile hands your browser after it decides you're allowed through. The widget runs its checks, and when it's satisfied it drops a long string into that hidden field. The server then sends that string to Cloudflare's siteverify endpoint to confirm it's real before trusting the request. No valid token, no entry.

Where the token comes from

When a page loads Turnstile, it renders a widget tied to a sitekey (the public identifier for that site's Turnstile config). The widget scores the browser in the background. If it passes, Turnstile writes the token into an input named cf-turnstile-response, usually inside the form you're about to submit, and optionally fires a JavaScript callback with the same value.

So the token has three properties that matter for automation:

It's tied to the sitekey it was issued for. A token from one sitekey won't validate against another.
It's single-use. The server redeems it once at siteverify; replay the same token and Cloudflare rejects it.
It's short-lived. Turnstile tokens expire around 300 seconds after issue. Grab one and sit on it, and it goes stale.

If you're not sure where the sitekey on your target comes from, that's a two-minute job covered in how to find a Turnstile sitekey.

How the token gets submitted

In the normal browser flow, the widget fills the field and you just submit the form. The token rides along as a POST parameter:

POST /login HTTP/1.1
Content-Type: application/x-www-form-urlencoded

email=you@example.com&password=...&cf-turnstile-response=0.abc123LongOpaqueString...

On the server, the site takes that value and verifies it:

# server side, on the site you're submitting to
POST https://challenges.cloudflare.com/turnstile/v0/siteverify
  secret=<the site's secret key>
  response=0.abc123LongOpaqueString...
# -> {"success": true, ...}

You never see the secret key; that's the site's. Your job as the client is only to produce a valid response value and send it with the form.

Getting the token without running a browser

You have two ways to produce that token. Drive a real browser, let the widget solve, and scrape the field. Or ask a solving API to return the token directly. The second skips keeping a headless browser alive for every request.

import requests

token = requests.post(
    "https://api.peak.fo/solve",
    headers={"X-API-Key": "pk_your_api_key"},
    json={
        "task_type": "turnstiletask",
        "url": "https://target.com/login",
        "sitekey": "0x4AAAAAAAxxxxxxxx",
        "proxy": "http://user:pass@ip:port",
    },
    timeout=30,
).json()["data"]["token"]

# now submit it before it expires (~300s)
requests.post("https://target.com/login", data={
    "email": "you@example.com",
    "password": "...",
    "cf-turnstile-response": token,
})

On a typical target that comes back in about one to one and a half seconds, and Peak only charges when the solve lands, so a miss costs nothing. The token you get is a normal cf-turnstile-response value; the server can't tell it apart from one a browser produced, because it isn't different.

Why a token gets rejected

Almost every "my token doesn't work" case is one of four things:

It expired. You solved, then waited too long to submit. Solve immediately before the request that needs it.
You reused it. Tokens are single-use. Every submission needs a fresh one.
Wrong sitekey. You solved against a sitekey that isn't the one on the page you're posting to.
Mismatched context. Some deployments tie the token to an action or the page's IP. Solve through the same proxy you'll submit from, and pass the action if the widget sets one.

FAQ

What is cf-turnstile-response?

It's the hidden form field that holds the token Cloudflare Turnstile issues when a browser passes the challenge. The site sends that token to Cloudflare's siteverify endpoint to confirm the visitor cleared Turnstile before accepting the request.

How long is a Turnstile token valid?

Around 300 seconds. It's also single-use, so you need a fresh token for each submission and you should submit it right after you get it.

Can I reuse a cf-turnstile-response token?

No. The server redeems it once at siteverify. Solve again for the next request. See the Turnstile solving guide for the full flow, or pricing to start.

Need Turnstile tokens on demand? Grab a key free at peak.fo.

What is Cloudflare Turnstile? How it works, and what the integration looks like

Peak Fo — Mon, 21 Sep 2026 07:14:34 +0000

Cross-posted from blog.peak.fo. I work on Peak, the solving API mentioned at the end.

Cloudflare Turnstile is a CAPTCHA replacement that decides whether a visitor is human by watching how their browser behaves, instead of making them label images. Most visitors see nothing more than a checkbox that ticks itself. Behind that checkbox, Cloudflare runs a set of browser checks and issues a token the site uses to confirm the visit is legitimate.

Below: what it checks, the three modes, what the integration looks like from the site's side, and why so many sites switched to it.

How Turnstile works

When a page loads Turnstile, a small script runs in the visitor's browser. It looks at signals the browser gives off: the JavaScript environment, how rendering behaves, and subtle traits that separate a real browser from a headless script. Cloudflare pairs that with its own reputation data for the visitor's IP, since it sits in front of a large chunk of the web and has seen that address before.

If the checks pass, Turnstile writes a token into a hidden field called cf-turnstile-response. The site sends that token to its server, the server asks Cloudflare to verify it, and the visit proceeds. No puzzle, no images, usually no interruption. When Cloudflare is less sure, it may show an actual checkbox to click, but the heavy lifting is invisible.

The three modes

Turnstile comes in three flavors, and the difference is how visible it is:

Non-interactive: runs silently, no click. The common case.
Managed: Cloudflare decides in the moment whether to show a checkbox, based on how risky the visit looks.
Invisible: no widget renders at all. The check happens in the background.

All three end the same way: a token that proves the check ran. The mode only changes whether the visitor notices.

What it looks like on the page

From the site owner's side, there are two pieces. First, the client script and a widget element carrying the public sitekey:

<script src="https://challenges.cloudflare.com/turnstile/v0/api.js" async defer></script>

<form method="POST" action="/login">
  <div class="cf-turnstile" data-sitekey="0x4AAAAAAAxxxxxxxxxxxx"></div>
  <button type="submit">Log in</button>
</form>

When the widget finishes, it adds the cf-turnstile-response field to the form, so the token rides along with the POST. Second, the server sends that token to Cloudflare's siteverify endpoint together with the site's secret key:

curl -s https://challenges.cloudflare.com/turnstile/v0/siteverify \
  -d "secret=YOUR_SECRET_KEY" \
  -d "response=TOKEN_FROM_THE_FORM"

The JSON that comes back has "success": true or an error code. Two details from Cloudflare's docs matter later if you automate against it: a token expires after 300 seconds, and each token can be validated only once. A replayed token is rejected.

The sitekey is public and sits in the page source. The secret key stays on the server, which is why a token can't be forged by someone who only has the page.

Why sites use it

Two reasons carry most of the switch. It's free with unlimited challenges, which is not true of reCAPTCHA Enterprise or hCaptcha's paid tiers. And it doesn't hand visitor data to an advertising network, which matters for privacy and for the regulations around it. Add that most people never have to solve anything, and you get fewer abandoned forms. It also doesn't require the site to route its traffic through Cloudflare: you need a Cloudflare account to get keys, and you can drop the widget into any page.

What Turnstile is not

It isn't a wall. Turnstile raises the cost of automated abuse; it doesn't make it impossible. The token is only as trustworthy as the browser and IP behind it, which is why, on the automation side, solving Turnstile comes down to presenting a clean environment and a good IP rather than defeating a puzzle.

If you're doing legitimate automation, scraping public data, or testing your own forms, see how to solve Cloudflare Turnstile for the practical version. Curious how it compares with the alternatives? We wrote up Turnstile, reCAPTCHA, and hCaptcha side by side.

If you'd rather not run the browser side yourself, Peak's API takes the sitekey and page URL and returns a token you put in the cf-turnstile-response field:

import requests

resp = requests.post(
    "https://api.peak.fo/solve",
    headers={"X-API-Key": "YOUR_API_KEY"},
    json={
        "task_type": "turnstiletask",
        "url": "https://target.com/",
        "sitekey": "0x4AAAAAAAxxxxxxxxxxxx",
    },
    timeout=60,
)
token = resp.json()["data"]["token"]

Pricing is $0.90 per 1,000 successful solves, dropping to $0.35 at the largest package, and failed solves aren't billed. New accounts get 1,000 free solves to test with. Parameter reference is in the Peak docs.

FAQ

What is Cloudflare Turnstile in simple terms?

It's a CAPTCHA that checks your browser in the background and gives the site a token proving you're likely human, instead of asking you to solve a puzzle. Most visitors just see a checkbox that completes on its own.

Is Cloudflare Turnstile free?

Yes, it's free for site owners with unlimited challenges, which is a big part of why it's grown so fast against paid options.

Does Turnstile track users?

Turnstile is built to collect minimal data and doesn't feed a third-party ad network, which is one of its main selling points over reCAPTCHA.

How long does a Turnstile token last?

300 seconds, and it can be verified once. After that you need a fresh token.

Working with Turnstile in your own automation? Start free at peak.fo.

How to Find a Cloudflare Turnstile Sitekey (Including When JavaScript Loads It)

Peak Fo — Sun, 20 Sep 2026 07:15:06 +0000

Cross-posted from blog.peak.fo. I work on Peak, the solving API used in the example below.

Before you can solve a Cloudflare Turnstile, you need its sitekey. It's a short public string, real ones start with 0x4, and it's sitting in the page's HTML in plain sight. Here's how to grab it in a few seconds, and what to do when the widget is loaded dynamically and doesn't show up in the raw source.

Quick answer: open the page, search the HTML for data-sitekey or 0x4, and copy the value. That's the sitekey. The rest of this covers the cases where it isn't that simple.

The fast way: read it off the widget

Turnstile renders into an element that carries the key as a data-sitekey attribute:

<div class="cf-turnstile" data-sitekey="0x4AAAAAAAxxxxxxxxxxxx"></div>

In a browser, open DevTools, hit the elements panel, and search (Ctrl+F inside it) for cf-turnstile or data-sitekey. Copy the value. Done. If you'd rather stay in the terminal, curl the page and grep for the pattern:

curl -s https://target.com/ | grep -oE 'data-sitekey="[^"]+"' | head -1

When it's not in the raw HTML

Plenty of sites load Turnstile with JavaScript after the page renders, or configure it through the turnstile.render() call instead of a data attribute. Then a plain curl shows nothing, because the key only appears once scripts run. Two options.

Search the JavaScript. The key still has to reach the browser, so grep the page's scripts for sitekey or the 0x4AAAAAAA prefix. It's often passed as an argument to turnstile.render():

turnstile.render('#container', { sitekey: '0x4AAAAAAAxxxxxxxxxxxx' });

Or read it from a real browser. Load the page in a headless browser, wait for the widget, and pull the attribute:

from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    page = p.chromium.launch().new_page()
    page.goto("https://target.com/")
    page.wait_for_selector("[data-sitekey]")
    sitekey = page.get_attribute("[data-sitekey]", "data-sitekey")
    print(sitekey)

There's a third place to look. Once the widget has rendered, it loads a frame from challenges.cloudflare.com, and the sitekey is one of the path segments in that frame's URL, for example .../turnstile/f/av0/rch/fmb9f/1x00000000000000000000AA/light/fbE/new/normal. The iframe sits inside a closed shadow root, so querySelector won't find it, but the frame list will. In Playwright that's [f.url for f in page.frames]. In DevTools, expand the widget's #shadow-root and read the iframe src.

Test keys look different

Cloudflare publishes dummy sitekeys for development, and some demo pages use them. They don't start with 0x4, so a grep for that prefix will miss them:

Sitekey	Behavior
`1x00000000000000000000AA`	always passes
`2x00000000000000000000AB`	always blocks
`3x00000000000000000000FF`	forces an interactive challenge

I checked this against Cloudflare's own demo page (demo.turnstile.workers.dev): its widget uses 1x00000000000000000000AA. If you're pulling keys out of a page and get one of these, you're looking at a test widget, not a protected form.

The sitekey isn't a secret

Worth saying plainly: the sitekey is public by design. It's the client-side identifier the widget needs, so it's always exposed in the page. The private half (the secret key) lives on the site's server and never reaches you, and you don't need it. To solve the challenge you only need the public sitekey plus the page URL.

Once you have both, you're ready to solve. The full flow, with code and the token submission step, is in how to solve Cloudflare Turnstile, and the parameter reference is in the Peak docs.

Here's the whole thing with Peak's API, which is the one I work on. Send the sitekey and page URL, get a token back, and put it in the form's cf-turnstile-response field:

import requests

resp = requests.post(
    "https://api.peak.fo/solve",
    headers={"X-API-Key": "YOUR_API_KEY"},
    json={
        "task_type": "turnstiletask",
        "url": "https://target.com/",
        "sitekey": "0x4AAAAAAAxxxxxxxxxxxx",
    },
    timeout=60,
)
token = resp.json()["data"]["token"]

Pricing is $0.90 per 1,000 successful solves, dropping to $0.35 at the largest package, and failed solves aren't billed. New accounts get 1,000 free solves to test with.

FAQ

Where is the Turnstile sitekey?

In the page HTML, as the data-sitekey attribute on the widget element, or passed to turnstile.render() in the page's JavaScript. Production keys start with 0x4; Cloudflare's dummy test keys don't (see above).

Is the sitekey secret?

No. The sitekey is public and always visible in the page. The secret key is separate, stays on the site's server, and you never need it to solve the challenge.

Have the sitekey and URL? Start solving free at peak.fo.

The cf_clearance cookie, explained (and how to reuse it without getting re-challenged)

Peak Fo — Sat, 12 Sep 2026 07:16:46 +0000

Cross-posted from blog.peak.fo. I work on Peak, the solving API used in the example below.

You solve Cloudflare's "checking your browser" page once, and then every follow-up request gets challenged again. The thing you're missing is a cookie: cf_clearance. Hold onto it correctly and the rest of your session sails through. Handle it wrong and you're stuck in a loop.

cf_clearance is the cookie Cloudflare sets after a browser passes the 5-second interstitial (or a managed challenge). It's proof that this visitor cleared the check, so Cloudflare stops re-challenging. For automation, that cookie is the whole prize: get it once, reuse it, skip the challenge on subsequent requests.

Why you can't just copy the cookie and go

Here's the part that trips people up. cf_clearance isn't portable. Cloudflare binds it to two things: the IP address that earned it and the user-agent of the browser that earned it. Move the cookie to a different IP or send it with a different user-agent, and Cloudflare throws it out and challenges you again.

So reuse has three rules. Same cookie, same IP, same user-agent. Break any one and it stops working. That's why a sticky session proxy matters here: you need the IP that got the clearance to stay yours for the life of the session.

Getting cf_clearance with a solving API

You can drive a real browser to earn the cookie, or call an API that returns it. With Peak, the cloudflare5stask gives you back the cookie, the matching user-agent, and the supporting headers in one response, so you don't have to keep a browser alive.

import requests

API_KEY = "pk_your_api_key"
TARGET = "https://target.com/"            # trailing slash is required
PROXY = "http://user:pass@ip:port"        # sticky session: same IP for the whole session

sol = requests.post(
    "https://api.peak.fo/solve",
    headers={"X-API-Key": API_KEY},
    json={"task_type": "cloudflare5stask", "url": TARGET, "proxy": PROXY},
    timeout=60,
).json()["data"]

user_agent = sol["headers"]["user-agent"]   # reuse this exact string
proxies = {"http": PROXY, "https": PROXY}   # and this exact proxy

session = requests.Session()
session.headers["User-Agent"] = user_agent
for name, value in sol["cookies"].items():  # cf_clearance + __cf_bm
    session.cookies.set(name, value, domain="target.com")

# finalize the challenge once: POST the returned attributes back to the page
session.post(
    TARGET,
    data=sol["attributes"],
    headers={"Referer": f"{TARGET}?__cf_chl_tk={sol['cf_rt']}"},
    proxies=proxies,
    timeout=30,
)

# from here on, plain requests with the same cookies, user-agent and IP go through
page = session.get("https://target.com/protected", proxies=proxies, timeout=30)
print(page.status_code)

The response carries cf_clearance plus __cf_bm (Cloudflare's bot-management cookie), the user-agent string that matches them, and a set of attributes you POST back to the page once to finalize the challenge. Set all of it together. The most common mistake is grabbing cf_clearance alone and sending it with your own default user-agent, which doesn't match, so Cloudflare rejects it.

How long does it last?

Clearance cookies are short-lived by design, and Cloudflare tunes the lifetime per site, so don't hard-code an assumption. Treat it as a session token: use it while it works, catch the moment a request gets challenged again, and solve once more to refresh. Because Peak only bills successful solves, a refresh here and there costs a tenth of a cent each ($1.00 per 1,000 successful solves for the 5-second task) and nothing when a solve misses.

Turnstile vs the 5-second challenge

Don't confuse the two. Turnstile is a widget that returns a token you submit with a form; the 5-second challenge is an interstitial that returns a cookie you reuse on requests. Different mechanisms, different handling. If you're dealing with the widget instead, read how to solve Cloudflare Turnstile. The full parameter reference for both is in the Peak docs.

FAQ

What is the cf_clearance cookie?

It's the cookie Cloudflare sets once a browser passes the 5-second or managed challenge. It tells Cloudflare this visitor already cleared the check, so subsequent requests aren't challenged, as long as they come from the same IP with the same user-agent.

Can I reuse cf_clearance across IPs?

No. Cloudflare binds it to the IP and user-agent that earned it. Use a sticky session proxy so the IP stays constant, and always send the matching user-agent.

How do I get cf_clearance automatically?

Run the cloudflare5stask against the protected URL with a sticky proxy; the response returns the cookie and the matching user-agent to reuse. See pricing to start.

Clearing Cloudflare at scale? Grab a key free at peak.fo.

Handling Cloudflare Turnstile in Playwright and Puppeteer (inject the token, skip the stealth fight)

Peak Fo — Fri, 11 Sep 2026 07:16:07 +0000

Cross-posted from blog.peak.fo. I work on Peak, the solving API used in the examples below.

Your Playwright script loads the page, the Turnstile widget sits there spinning, and it never flips to the green check. So the form won't submit, and your run dies at the gate. The frustrating part is that the same script works when you drive it by hand. That gap is the whole problem, and there are two clean ways to close it.

Either you harden the browser enough that Turnstile trusts it and solves on its own, or you get the token out-of-band and inject it into the page. The second is more reliable under automation, because you stop fighting fingerprint detection and just hand the form what it needs.

Why the widget stalls under automation

Turnstile scores the browser in the background. Headless Chromium leaks signals that a normal browser doesn't: automation flags, a thin canvas and WebGL fingerprint, timing that's too clean. When the score comes back low, the widget quietly refuses to issue a token. No error, just an endless spinner. Puppeteer has the same issue for the same reasons.

You can chase this with stealth plugins, and sometimes it's enough. But you're now maintaining an anti-detection layer that breaks every time Cloudflare adjusts its model. If you only need the token, there's less moving machinery in getting it directly.

Inject a solved token into Playwright

Solve with the API, then drop the token into the hidden cf-turnstile-response field the form reads on submit:

import requests
from playwright.sync_api import sync_playwright

URL = "https://target.com/login"
SITEKEY = "0x4AAAAAAAxxxxxxxx"
PROXY = "http://user:pass@ip:port"

def solve_token():
    return requests.post(
        "https://api.peak.fo/solve",
        headers={"X-API-Key": "pk_your_api_key"},
        json={"task_type": "turnstiletask", "url": URL, "sitekey": SITEKEY, "proxy": PROXY},
        timeout=30,
    ).json()["data"]["token"]

token = solve_token()  # ~1 to 1.5s on a typical target

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

    page.evaluate(
        """(token) => {
            let el = document.querySelector('[name="cf-turnstile-response"]');
            if (!el) {
                el = document.createElement('input');
                el.type = 'hidden';
                el.name = 'cf-turnstile-response';
                (document.forms[0] || document.body).appendChild(el);
            }
            el.value = token;
        }""",
        token,
    )

    page.fill('input[name="email"]', "you@example.com")
    page.fill('input[name="password"]', "...")
    page.click('button[type="submit"]')

The form posts the token exactly as a browser-solved one would, because it is one. For the details of what that token is and why it expires, see the cf-turnstile-response token, explained.

The same idea in Puppeteer

// Node + Puppeteer
const token = await solveToken(); // POST to api.peak.fo/solve, read data.token

await page.goto(URL);
await page.evaluate((token) => {
  let el = document.querySelector('[name="cf-turnstile-response"]');
  if (!el) {
    el = document.createElement('input');
    el.type = 'hidden';
    el.name = 'cf-turnstile-response';
    (document.forms[0] || document.body).appendChild(el);
  }
  el.value = token;
}, token);

await page.click('button[type="submit"]');

If you'd rather not hand-roll the injection, the same flow is packaged: playwright-turnstile on PyPI for Playwright, and puppeteer-extra-plugin-turnstile on GitHub for Puppeteer. Both read the sitekey, request the token, set the field and fire the callback.

Two things that trip people up

Callbacks. Some pages don't read the field on submit; they act on a JavaScript callback set with data-callback. If the button stays disabled after you set the field, find the callback name and call it: page.evaluate((t) => window.myTurnstileCb(t), token).

Timing. Turnstile tokens are single-use and expire in roughly 300 seconds. Solve right before you submit, not at the top of a long script, or the token goes stale before the form sees it.

If you're weighing whether to keep the browser at all, solving API vs headless browser lays out when each approach is the right call. The end-to-end flow lives in the Turnstile solving guide.

FAQ

Why won't Turnstile solve in headless Playwright?

Headless Chromium leaks automation signals and a weak fingerprint, so Turnstile scores the browser low and never issues a token. Either harden the browser against detection or solve the token out-of-band and inject it into the cf-turnstile-response field.

Do I need stealth plugins?

Not if you inject a solved token. Stealth helps when you want the widget itself to pass, but it needs ongoing maintenance as Cloudflare changes. Injecting a token sidesteps the fingerprint fight entirely.

How do I handle a Turnstile callback?

If the page uses data-callback, setting the hidden field may not be enough. Read the callback name from the widget config and call it with the token via page.evaluate. See pricing to start.

Automating past Turnstile? Grab a key free at peak.fo.

FlareSolverr not working in 2026? Why it times out, and what to use instead

Peak Fo — Wed, 09 Sep 2026 07:19:20 +0000

Cross-posted from the Peak blog. Disclosure: I work on Peak, the solve API mentioned below.

FlareSolverr used to be the easy answer: run a container, POST a URL, get back cookies and HTML. In 2026 you're more likely to get Challenge not detected, a timeout, or a response that's still the "Just a moment…" page. The approach itself, driving a real browser through the challenge, is the thing that's breaking. Here's why, and what actually gets you the token.

The short version

FlareSolverr solves the old interstitial by loading it in a headless browser and waiting for the redirect. Cloudflare Turnstile and the managed challenge now fingerprint the browser and score the IP, and a headless browser on a datacenter address fails both checks, so the redirect never comes and FlareSolverr times out.

Why the browser approach breaks

It waits for a redirect that no longer happens. FlareSolverr's model is "open the challenge page, wait for Cloudflare to clear it." Turnstile is an interactive widget, not a wait-and-redirect page, so there's nothing for it to wait on.
Headless fingerprints get flagged. Cloudflare reads canvas, WebGL, audio, and behavioral signals. A stock headless Chrome, even a patched one, leaves tells the challenge is specifically looking for.
Datacenter IPs score badly. Even a perfect browser gets a low trust score from a datacenter or flagged IP, and the challenge stays up.
Maintenance lags Cloudflare. FlareSolverr depends on browser-patching projects keeping pace with detection changes. When Cloudflare ships an update, there's a window where everything downstream returns timeouts.

How to confirm it's the challenge, not your setup

If the FlareSolverr response solution.response still contains cf-turnstile or Just a moment, the browser didn't pass. No amount of longer maxTimeout will fix that, because it's not a timing problem. It's a detection problem.

The fix: skip the browser fleet, get the token from an API

Instead of maintaining a headless browser and hoping its fingerprint holds, send the sitekey and your proxy to a solve API and get the cf-turnstile-response token back. One request, about a second, and the browser work happens on the solver's side:

curl -X POST https://api.peak.fo/solve \
  -H "X-API-Key: pk_your_key" \
  -H "Content-Type: application/json" \
  -d '{"task_type":"turnstiletask","url":"https://target.example/","sitekey":"0x4AAA...","proxy":"http://user:pass@ip:port"}'

# -> {"success": true, "data": {"token": "0.abc..."}, "cost": 0.0009}

You inject that token into the form's cf-turnstile-response field (or send it to the site's verify endpoint) and continue. Passing your own proxy matters: Cloudflare ties clearance to the requesting IP, so the solve runs from the same address as your crawl.

For the managed 5-second challenge, the same API returns a cf_clearance cookie and the matching user-agent instead of a widget token. Set both on your session and re-request.

If you'd rather keep it in your existing tooling

You don't have to call the API directly. If your scraper is built on a common library, a wrapper does the detect-solve-inject for you:

playwright-turnstile and selenium-turnstile for browser automation
cloudscraper-turnstile and turnstile-curl for HTTP clients
scrapy-turnstile for Scrapy

Under the hood they all call the same one-request Peak API, so you get the token without running or patching a browser.

What it costs vs. a self-hosted fleet

FlareSolverr is free to install but not free to run. You pay in servers, residential proxies, and the hours spent chasing detection updates. A solve API is pay-per-success: from $0.90 per 1,000 down to $0.35 at volume, and failed solves cost nothing. New accounts get 1,000 free solves, no card, so you can measure the success rate on your own target before switching anything.

Get a free key · Turnstile docs · 5s challenge docs

Use this for automation, QA, monitoring, and scraping public data you're authorized to access. Respect each site's Terms of Service and robots.txt.

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.