Configuration
Configuration now centers on the API contract rather than SDK options. The important boundaries are client_id, key class, allowed origins, project defaults, and the runtime-safe project config exposed to browsers.
Core
Identity and keys
client_id
Public project identifier used by both browser and server flows to resolve defaults and config.
Publishable key
Browser-safe key used only for activation-backed traffic. It must be bound to allowed origins.
Secret key
Server-only key for canonical backend calls against /v1/jobs, /v1/decisions, and /v1/beacons.
Project config
Runtime defaults
Format and label defaults
Preferred formats, native template hints, disclosure labels, and other non-secret defaults are resolved from the authenticated key's project and client_id so browser renderers do not need embedded secrets.
Allowed origins and browser safety
Allowed origins gate publishable-key activation. Browser-safe integration is not just about the key prefix; it depends on server-side origin enforcement.
Operational notes
Change behavior
Config propagation
Changes apply through the active project config path. Browser integrations pick them up on the next activation or the next initialization cycle.
Rate limits
Public routes enforce per-key limits and return the standard error envelope with Retry-After on 429 responses.
Runtime rules
Rate limits and CORS
| Surface | Key type | Origin behavior | Limit behavior |
|---|---|---|---|
/v1/jobs, /v1/decisions, /v1/beacons | Secret key | Server-to-server requests do not depend on browser origin allowlists. | Per-key buckets; 429 includes Retry-After. |
/v1/browser/activate | Publishable key | The request origin must match the key's allowed origins. | Publishable-key and browser-IP buckets protect activation. |
| Browser token calls | Activation token | Preflight can succeed for candidate origins; the actual request is still checked against stored project/key state. | Separated from secret-key traffic so sandbox and live integrations do not share counters. |
Lifecycle
Key rotation and compatibility
Rotation
Rotate keys from the dashboard, copy the newly revealed value once, and update clients before removing old credentials. Existing revoked keys should be treated as unavailable immediately unless your dashboard shows a grace deadline.
Compatibility aliases
Older public wrapper and browser activation paths remain compatibility aliases. New snippets and docs should use canonical /v1 routes.
Need rollout review?
Start in the dashboard, choose Script Tag or Server API, and use contact only when you need rollout review, enterprise coordination, or non-standard integration help. Billing beacon rules live in the API concepts guide.