Turnstile vs Cloudflare challenge: what actually differs

Two products, one platform

Cloudflare's own docs describe Turnstile as running on "the same underlying technology powering" the Challenge Platform, offered "anywhere on your site in a less-intrusive way". That shared engine is why the two get conflated. The deployment model is where they diverge, and the difference is not cosmetic.

A Turnstile widget does not mean the site is behind Cloudflare. The docs are explicit: Turnstile "can be embedded into any website without sending traffic through Cloudflare". An interstitial challenge page is the opposite — it can only exist on a zone proxied through Cloudflare, because Cloudflare has to intercept the request to serve it.

Who issues each

Cloudflare documents three issuance paths, and only one of them is Turnstile.

• **WAF products** — custom rules, rate limiting rules and IP Access rules issue interstitial challenge pages. Bot Fight Mode and Super Bot Fight Mode do the same.
• **Bot Management** — JavaScript Detections inject a snippet into HTML responses to gather client-side signals. This one does not interrupt the visitor at all; it runs on every HTML request and produces a pass/fail that WAF rules can then act on.
• **Turnstile** — the site owner drops a sitekey into a <div> and decides for themselves what to do with the resulting token.

The practical read: a challenge page is a decision the *infrastructure* made about a request. A Turnstile token is a decision the *application* asked for about a user action. Nothing forces those two decisions to agree, and a site can run both at once.

What a token attaches to, and for how long

This is where handling actually diverges, and where most integration bugs live.

**Turnstile token.** When the widget sits inside a <form>, it writes a hidden input named cf-turnstile-response. Your server takes that value and POSTs it to https://challenges.cloudflare.com/turnstile/v0/siteverify with your secret key. The response carries success, challenge_ts, hostname, error-codes, and echoes back the action and cdata the widget was configured with — so you can confirm the token was minted for the form you think it was. Tokens expire after 300 seconds and each can be validated exactly once; replaying one returns timeout-or-duplicate.

curl -s https://challenges.cloudflare.com/turnstile/v0/siteverify \
  -d "secret=$TURNSTILE_SECRET" \
  --data-urlencode "response=$CF_TURNSTILE_RESPONSE" \
  -d "remoteip=203.0.113.10"

# {"success":true,"challenge_ts":"2026-08-13T09:14:02.000Z",
#  "hostname":"staging.example.com","action":"login","cdata":""}

The token is inert until you redeem it. If your backend never calls siteverify, the widget is decoration — Cloudflare's docs call enforcing tokens with siteverify "critical", because an unverified token proves nothing.

**Challenge page clearance.** Passing an interstitial does not give you a value to submit. It gives you a cf_clearance cookie, which Cloudflare describes as storing "the proof of challenge passed" and which "is used to no longer issue a challenge if present". It is set with SameSite=None; Secure; Partitioned, is tied to the specific visitor and device it was issued to, and its lifetime is the zone's Challenge Passage setting — 30 minutes by default, with Cloudflare recommending 15 to 45. Challenge Passage does not apply to rate limiting rules.

Telling them apart in a response

You rarely need to guess. Each leaves a distinct signature.

• **Challenge page** — the response carries the header cf-mitigated: challenge. That header is present for every challenge page type and challenge is its only valid value. The response body is text/html regardless of what you originally requested, which is why an interstitial firing on an XHR endpoint corrupts a single-page app instead of merely delaying it.
• **Turnstile** — the page HTML loads https://challenges.cloudflare.com/turnstile/v0/api.js, contains a div.cf-turnstile carrying a public data-sitekey, and (inside a form) grows a hidden cf-turnstile-response input. The sitekey is public by design; the secret key never leaves your server.

fetch("/my-api-endpoint").then((response) => {
  if (response.headers.get("cf-mitigated") === "challenge") {
    // Interstitial challenge, not your API's response body.
  } else {
    // Process response as usual.
  }
});

One more note on the api.js URL: Cloudflare requires it be fetched from that exact origin. "Proxying or caching this file will cause Turnstile to fail when future updates are released." Mirroring it into your own bundle is a slow-motion outage.

Where the line genuinely blurs: pre-clearance

Pre-clearance is the one feature that crosses the boundary, and it is worth knowing about precisely because it breaks the tidy split above.

With pre-clearance enabled on a widget, Turnstile issues a cf_clearance cookie *in addition to* the usual one-time token. A visitor who passes the embedded widget is then exempt from WAF challenges on the same zone for the Challenge Passage duration. The clearance level is set at widget creation or modification through the Turnstile API's clearance_level field, with values interactive, managed, jschallenge and no_clearance — higher levels bypass more challenge types.

The requirement is that "the hostname of the Turnstile widget matches the zone with the WAF rules". A widget on a domain that is not proxied through Cloudflare cannot pre-clear anything, because there is no edge in the path to honour the cookie. Cloudflare recommends this pattern for API endpoints and SPAs specifically because interstitials cannot interrupt an XHR without breaking it.

"Managed" and "non-interactive" mean two different things

A large share of the confusion in this space is one overloaded vocabulary. The same two adjectives name a Turnstile widget mode and an interstitial challenge type, and they are not the same setting.

So "we use a managed challenge" is ambiguous on its own. Ask whether it renders in the page or in place of the page. That single question resolves it.

Why they need different handling in automation

If you are automating against properties you own or are authorised to test — QA suites, CI, uptime probes, staging environments, verifying your own anti-bot configuration actually fires — the two shapes need different code paths.

**Turnstile** is a value problem. You know the sitekey (it is in the page) and the page URL. You need a token, and then you place it wherever your own application expects it: the cf-turnstile-response field, a JSON body, a header. Nothing is set at the network layer, and the token is dead after 300 seconds or one redemption, whichever comes first.

**A challenge page** is a session problem. There is no field to fill. The clearance rides on subsequent requests to the zone, so the thing that receives the challenge and the thing that makes the follow-up request have to look like the same client — same egress IP above all, per Cloudflare's own constraint.

SolveGate covers both shapes behind one endpoint. POST /v1/solve takes a gate of turnstile or waf, plus sitekey and url, authenticated with a bearer secret key. Tokens typically come back in under 1.5 seconds. GET /v1/solve/{id} polls an async solve and is never billed.

# Turnstile widget on a staging login form you own.
curl -s https://api.solvegate.io/v1/solve \
  -H "Authorization: Bearer $SOLVEGATE_KEY" \
  -H "Content-Type: application/json" \
  -d '{
        "gate": "turnstile",
        "sitekey": "0x4AAAAAAABbbbCCCCddddEE",
        "url": "https://staging.example.com/login",
        "action": "login"
      }'

import { SolveGate } from "solvegate";

const sg = new SolveGate(process.env.SOLVEGATE_KEY);

// Interstitial challenge page in front of a host you control.
const solve = await sg.solve({
  gate: "waf",
  sitekey: "0x4AAAAAAABbbbCCCCddddEE",
  url: "https://staging.example.com/",
  proxy: process.env.EGRESS_PROXY, // keep egress stable across the exchange
});

console.log(solve.token, solve.solve_ms, solve.billed);

Pass the same egress proxy to the solve that your follow-up requests will use. Splitting them across two IPs is the challenge-loop failure Cloudflare documents, not a solver defect.

For wiring either path up before you point it at anything real, Cloudflare publishes dummy keys that work on every domain including localhost: sitekey 1x00000000000000000000AA always passes, 2x00000000000000000000AB always fails, 3x00000000000000000000FF forces an interactive challenge; secret 1x0000000000000000000000000000000AA always passes validation and 3x0000000000000000000000000000000AA returns a token-already-spent error. SolveGate's own sk_test_ keys return a deterministic SANDBOX.-prefixed response so you can exercise your error handling without spending anything.

Pricing is prepaid credits: $0.40 per 1,000 solves, down to $0.075 per 1,000 at volume. Failed solves are never billed. The first 1,000 solves are free. SDKs are published as solvegate on npm (Node 18+) and PyPI (Python 3.9+).

Common questions

Related

More in Glossary