Centinel AnalyticaDashboard
Find your site key and secret key, and see what a /validate response can include.
What you'll do here
Find and copy your keys (site key + secret key). Centinel normally generates both when it creates your organisation; check the Organisation page and regenerate either key if it is missing.
Review your policy rules. Add and order path-specific rules where you need different behavior. See Policy Rules.
Keys authenticate /validate; they do not enforce traffic. Before relying on blocks, add and
verify a matching policy rule. Then have your backend or platform integration act on the
/validate response.
The dashboard opens on Insights. Analytics has an endpoint tree showing which paths
actually receive traffic, which is the quickest way to decide what to protect first. Crawlers
holds the allowlist. Source-IP verification and allowlist membership determine access_allowed.
Threats shows what Centinel blocked and why. Press ⌘K (or
CtrlK) to jump to any of them.
API keys
Your keys are on the Organisation page, in the API Keys section. You have two keys:
- Site key (public): used in the browser script URL. Safe to expose.
- Secret key (sensitive): used as
x-api-keywhen your backend calls/validate. Keep this server-side only—store it in environment variables or a secret manager.
Never expose the secret key
The x-api-key is server-only. Don't put it in client-side code, HTML, or public repositories.
Crawler metadata
/validate responses can carry a crawler object identifying which crawler made the request. It
holds id, name, and access_allowed, plus category and rsl_category when the catalog entry
resolves. See Crawlers for the full schema.
/validate includes this object only when the validate_response_include_crawler feature flag is
enabled for your organisation. Crawler detection is always active, and you manage the allowlist on
the Crawlers page either way.
Once you have both keys, continue to: