Skip to main content
Keys are created in the dashboard under Settings, shown once at creation, and stored by us only as a hash. A key has a type and an environment, both fixed at creation.

Two types

A publishable key is bounded by scope, not by secrecy: a leaked one can at most add decisions and events to your organisation. It also carries an origin allowlist, a list of exact https:// origins; a browser request from any other origin is a 403. The allowlist stops a third-party page from riding your key cross-site; it is not server-side authentication, which is why the key can do nothing else. Never put a secret key in browser code, and never use a generic CURIOUS_API_KEY variable name in a browser bundle, where a build step could substitute the wrong one. The server SDK refuses a publishable key; the browser SDK refuses a secret one.

Two environments

A test key runs the full product against the same elements: declarations, variant generation, decisions, events. What it changes is accounting and identity, never semantics. Test decisions and events are excluded from learning and from the dashboard’s metrics, and a test key’s user_123 is a separate shadow user from a live key’s user_123, so test traffic can never read or change live user state. Start with a test key, see the whole loop run, then switch the key.

Rotation

Keys are immutable; rotate by creating a new one, deploying it, and revoking the old. Revocation takes effect within about thirty seconds. Revoke immediately if a secret key may have leaked.

Sending the key

On every request, over HTTPS only. The SDKs set it from their apiKey option and never log it.