Skip to main content
A sandbox key (lcrsb_…) exercises registered direct catalog endpoints and the compatibility chat endpoint with the live HTTP contract while simulating everything financial. Requests authenticate and validate like live direct calls, and billing headers use the live contract — but no credits are reserved or captured, no provider is called, and no call history is written. Response bodies are approximate fixtures for Perplexity, Anthropic, OpenAI, Groq, DeepSeek, OpenRouter, and Firecrawl; every other registered provider returns a generic sandbox envelope rather than its upstream schema. Use it to wire up an integration before funding an account, to run CI against the real request contract, and to avoid the cleanup work that live test identities require.

​
Create one

Sandbox keys are an enterprise workspace feature. From the dashboard, open API Keys → Workspace keys, select Create key, and choose Sandbox, or issue one from the API:
The raw key is returned once. Rotation, expiry, and credential audit events work exactly as they do for secret and publishable keys, through the same endpoints; the key is also manageable from the dashboard’s API Keys page.
Personal accounts cannot issue sandbox keys. Connect a Personal account through MCP OAuth and fund its prepaid balance before making live tool calls.

​
What a sandbox key can and cannot do

Per-key tools.enable endpoint scoping is honored: a call outside the key’s allow-list returns the live credential_endpoint_denied error, so you can test scoped integrations faithfully.

​
What a simulated call looks like

This OpenAI example returns an approximate chat-completion fixture. Do not use sandbox bodies to validate a provider SDK or provider-specific response parser. Alongside it:
  • x-locus-credits-charged and x-locus-credits-balance carry a simulated charge against a fixed simulated balance, denominated in your workspace’s real credits-per-dollar rate.
  • x-locus-cost-usd and x-locus-api-call-id are present as on live calls.
  • X-Locus-Sandbox: true marks every sandbox response.
For registered direct endpoints, request contract enforcement is the live one: unknown endpoints return the live 404, invalid bodies fail the endpoint’s real validator, inference output-budget rules apply, and Idempotency-Key is mandatory with the live parsing rules.

​
Retries and statelessness

The sandbox stores nothing. Identical retries under the same Idempotency-Key return the same x-locus-api-call-id and a byte-identical body, so retry handling can be tested. Reusing an Idempotency-Key for a different request is not detected — the live rail’s 409 conflict requires stored state the sandbox deliberately omits.
Sandbox authentication, request validation, idempotency, and billing headers exercise the direct-call contract. Response bodies are approximate or generic, and simulated balances never change. Verify provider-specific serialization and content against a live call before launch.
When your test suite runs on a sandbox key, there are no sessions, balances, policies, or end users to retire afterward — see Clean up integration tests for the workflows live test identities still need.