Skip to main content
Create a staging API key in API access in the dashboard. Its secret starts with chk_stg_. Call the same /v1/* endpoints or /mcp with this key.
Staging runs the real models at the organisation’s normal rates. Jobs have livemode: true and is_staging: true. Every staging call uses the shared live credit balance. Sandbox keys (chk_test_) use fixtures and separate test credits. Select Live in the dashboard, then choose Production, Staging or All on the overview, jobs and usage screens. The live balance is shared; the consumption shown follows your filter. Usage aggregates refresh hourly.

​
Credentials and retries

Use a separate staging key for your staging integration. Rotation preserves its environment. The environment comes from the key; a request body or header cannot override it. The same Idempotency-Key can be used independently in production, staging and sandbox. Retries within each environment return that environment’s original job.

​
Receive staging events

Create a webhook destination with Staging selected. It receives only staging job events. Production destinations receive only production events. Events carry both livemode and is_staging, including synthetic events sent with Send test. With no staging destination, retrieve results by polling.

​
Shared organisation resources

Staging classifies calls and their credit usage. Files, storage quotas, job access, endpoint permissions and live concurrency limits remain shared within the organisation. A staging key has the same live job access as a production key with the same scopes. Staging does not provide a separate workspace or a separate deployment of the models.