Centinel AnalyticaInterstitial Challenge
How Centinel verifies uncertain visitors with a brief in-browser challenge before granting access.
Overview
When /validate returns decision: "redirect", your backend serves a Centinel interstitial. It's a short-lived HTML page that runs a challenge in the visitor's browser. If they clear it, they continue to the protected content. If they fail or abandon it, the next request is blocked.
The interstitial is for traffic the validator can't confidently allow or block from request data alone. Rather than denying these visitors outright, which would also reject real users on VPNs, mobile networks, or unusual setups, Centinel gives them a way to prove they're human.
What a visitor sees
A brief loading page that usually completes in under a second. The page swaps itself out for the original content the moment the challenge passes. If the challenge needs interaction, like a CAPTCHA, the visitor completes it inline.
A session cookie remembers their cleared status, so they don't see another challenge as they navigate the rest of your site.
End-to-end flow
┌──────────────────────────────────────────┐
│ Visitor requests yoursite.com/article │
└────────────────────┬─────────────────────┘
│
▼
┌──────────────────────────────────────────┐
│ Your backend calls POST /validate │
│ with URL, IP, headers, _centinel cookie │
└────────────────────┬─────────────────────┘
│
▼
┌──────────────────────────────────────────┐
│ Validator decides │
└─────┬───────────────┬───────────────┬────┘
│ │ │
allow block redirect
│ │ │
▼ ▼ ▼
┌───────────┐ ┌─────────────┐ ┌────────────────────┐
│ Serve │ │ Serve block │ │ Serve interstitial │
│ content │ │ page │ │ HTML │
└───────────┘ └─────────────┘ └─────────┬──────────┘
│
▼
┌──────────────────────────────────┐
│ Browser sets session cookie │
│ Runs Centinel challenge │
│ (optional interactive step) │
└────────────────┬─────────────────┘
│
▼
┌──────────────────────────────────┐
│ Centinel records the result │
│ for that session │
└────────────────┬─────────────────┘
│
▼
┌──────────────────────────────────┐
│ Browser navigates to original URL│
│ — request now carries the proven │
│ session cookie │
└────────────────┬─────────────────┘
│
▼
┌──────────────────────────────────┐
│ /validate recognizes the cleared │
│ session — no re-challenge │
└──────────────────────────────────┘Walking through it:
The visitor requests a protected URL. Your backend calls POST /validate.
The validator can't confidently allow or block based on request data alone. It returns decision: "redirect" with an HTML interstitial as base64 in response_html.
Your backend returns the decoded interstitial HTML to the browser with HTTP 200. A session cookie is set so the visitor can be recognized on the way back.
The browser renders the interstitial. It runs Centinel's challenge logic, sometimes including an interactive step.
Centinel records the result. Passing the challenge gives the session an allow; failing gives it a block.
The interstitial sends the browser to the original URL. The session cookie is already in place, so the next /validate call recognizes the cleared visitor and skips the challenge.
Session continuity
After the challenge clears, every later /validate call recognizes the visitor and returns the same decision for as long as their session lasts. They browse the rest of your site normally.
If they come back after the session has expired, they start over. Whether they see another challenge depends on what their next request looks like.
Abandoned interstitials
If a visitor opens the interstitial and never completes the challenge (closes the tab, navigates away, leaves the browser idle), the session counts as failed and the next request is blocked.
What this gives you
Visitors see at most one challenge per session, so cleared traffic moves through your site without interruption. Automation that fails the challenge, or that never runs JavaScript at all, stays blocked.
You don't host or maintain the challenge itself. Centinel serves the HTML, runs the verification, and tracks the result. All you do is decode response_html and return it as the body of your response.