Glossary

Terms used in the dashboard and /validate responses. Linked pages cover anything that needs more than a paragraph.

Decisions

Allow

The validator concluded the request is OK. Your backend serves the original content.

Block

The validator denied the request. Your backend returns 403 with Centinel's block page in the body.

Redirect

The validator can't decide from request data alone, so it returns an interstitial challenge. Your backend serves the interstitial with HTTP 200; the browser runs the challenge and the next request continues.

Not matched

The URL isn't covered by your protected-endpoints config. No score, no decision: pass through unchanged.

Visitors

Crawler (identified)

Request's User-Agent matches a known crawler signature, like Googlebot or GPTBot. Identification alone does not prove the request really came from that crawler. See the crawler object for the full schema.

Crawler (verified)

An identified crawler that also passes ownership verification. Reverse DNS or known IP-range checks confirm the operator.

Crawler (allowed)

A verified crawler you've placed on your allowlist. Passes through without scoring.

Stealth crawler

A bot that tries to look like an ordinary browser. The validator catches it by collecting browser signals and spotting inconsistencies. For real browsers controlled by automation tools (Selenium, Playwright, Puppeteer), see Automated browser.

How a check works

Challenge

A short test the browser runs, sometimes including a CAPTCHA. Passing it clears the session; failing or skipping it ends in a block.

Interstitial

The HTML page Centinel serves on a redirect decision. Runs the challenge in the visitor's browser, then forwards them to the original URL. See Interstitial Challenge for the full flow.

Session

A run of requests sharing the same _centinel cookie. Once one request in a session clears the challenge, the rest of the session skips it.

Fingerprint

A composite signature of how the browser behaves at the network and JavaScript level. The validator compares it against what the User-Agent claims; a real Chrome should look like Chrome from every angle.

Block-reason categories

Header anomaly

HTTP headers are missing, contradictory, or shaped like a script rather than a browser. Real browsers send a consistent set of headers; bots and minimal HTTP libraries often don't.

Fingerprint mismatch

The request's network signature doesn't match what its User-Agent claims. For example, a request says it's Chrome but the network signature looks like Python or Go.

Bot identity

The request's User-Agent identifies it as a known bot or scraper HTTP client (such as python-requests or curl), and is not on your allowlist. Browser-automation frameworks like Selenium or Puppeteer fall under Automated browser instead.

Automated browser

A real Chrome or Firefox driven by Selenium, Playwright, Puppeteer, or a similar tool. They run JavaScript fine, but leave traces in the browser environment that the validator picks up.

Crawler impersonator

A request claims to be a well-known crawler like Googlebot, but its IP doesn't belong to that crawler's operator. Common in scrapers trying to bypass crawler-allow rules.

Suspicious network

Traffic came from a network type associated with abuse. Common sub-types you'll see in analytics:

• VPN — commercial VPN service. Legitimate users do use VPNs, so this is a signal weighed with the others, not an automatic block.
• Datacenter (DC) — IP belongs to a cloud or hosting provider. Most consumer traffic doesn't originate from datacenters; bots often do.
• Proxy — open or commercial HTTP proxy. Frequently used to mask the origin of automated traffic.
• Tor — a Tor exit node. Anonymity network with mixed legitimate and abusive use.

Challenge failure

The visitor got an interstitial and didn't clear it. Three ways this happens: the challenge failed, the verification was invalid, or the visitor abandoned the page.

See also