Each vendor leaves a different kind of cookie on the client. They are not interchangeable, and most failed scraping attempts come from treating one like another. These pages explain what each cookie actually proves.
The clearance receipt issued after a JS challenge, Managed Challenge or Turnstile flow. Lives about 30 minutes and dies if the IP or user agent changes.
A sensor ledger in three segments, rewritten on every response. The middle segment carries the verdict flag, which is why a fresh cookie can still be a blocking one.
The sensor verdict from Imperva's script. Short-lived (often 5–15 minutes), per-site, and bound to the session that solved it.
Clearance issued after DataDome's fingerprinting POST. Rotating proxies mid-session makes scoring worse, not better.
The signed pass issued after the sensor check: an encrypted payload with a score, a timestamp and an HMAC. Its lifetime inside the payload is not the same as the cookie’s Expires.
A challenge token bound to one domain and a roughly 180-second window. You need the challenge script URL to mint one; the token alone is not enough.
Cloudflare’s verdict about the client, refreshed about every 30 minutes. A verdict is not a pass — only cf_clearance skips a challenge.
Turnstile token — a widget output your own server verifies; it is not clearance and does not open the site by itself.
Sensor data — the payload Akamai's script builds; the cookie is derived from it, so a cookie without fresh sensor data ages badly.
Interstitial — the full-page challenge some vendors show before the resource loads; distinct from an inline CAPTCHA widget.
A Japanese edition of this glossary explains the Cloudflare, Akamai, Imperva and PerimeterX cookies: アンチボット Cookie 用語集.
An Indonesian edition explains the same two cookies: Glosarium cookie anti-bot.