Environments and the sandbox

Sandbox and live are separate projects

Each partner has a sandbox project and a live project. They carry different OAuth clients, so a sandbox token can never reach live data and vice versa, and they have independent rate-limit buckets — load-testing the sandbox never eats into your production allowance. Sandbox is fixed at the build tier (10 req/s, burst 50) regardless of your live tier, which is deliberate: sandbox is for correctness, live is for throughput.

Why the public ring has no sandbox

The public ring returns only published figures — there is no customer data, no decision, no money — so there is nothing to sandbox. You develop against it directly. The one caveat: the two public write endpoints (enquiries and consent) do record real rows, so treat them with the same care in development as in production.

Promoting to live

Build and verify against the sandbox, then swap your base URL and credentials for the live project. Because the two are separate projects, promotion is a configuration change, not a code change. Keep your sandbox project active after go-live for regression testing — it never touches production quotas or data.

Frequently asked questions

Can a sandbox token call the live ring?

No. Sandbox and live are separate projects with separate OAuth clients, so a sandbox credential only works against sandbox and a live credential only against live. This is a deliberate isolation boundary.

Why is sandbox limited to the build tier?

Sandbox is for verifying correctness, not for throughput testing, so it is fixed at the build tier (10 req/s, burst 50) whatever your live tier. Test your integration's logic there; test scale against live within your tier's ceiling.