API sandbox

A sandbox is an environment that behaves like the real API but is cut off from real consequences: payments are not charged, emails are not sent, shipments do not move. Payment providers, banks and shipping companies offer sandboxes so integrations can be built and tested without risk.

How it works

Sandboxes usually have their own base URL or credentials, seed data and test values that trigger specific outcomes — a card number that is always declined, an amount that always times out. Data in one developer's sandbox is isolated from another's, and can be reset to a known state.

The misconception

That passing in the sandbox means passing in production. Sandboxes simplify: they skip fraud checks, approve instantly, run with generous rate limits and old API versions. Treat them as a place to exercise behaviour, and keep a small set of production smoke tests for the differences.

Try it here

Every request here is isolated by an X-Sandbox-ID header, so your writes are invisible to other people's tests; reset yours from any docs page or with POST /api/_reset.

Sources

Mocks, stubs and test isolation — Martin Fowler

Other terms

Mocks, stubs and fakes — Three kinds of test double — stand-ins for a real dependency — that differ in what they do and what they check.
Mock API — A stand-in for a real API that returns realistic responses without the real system behind it.
Test fixture — The known data and state a test starts from, set up the same way on every run.
Contract testing — Testing that an API and its consumers agree on the shape of requests and responses, without running them together.
Smoke testing — A small, fast set of checks that the most important paths work at all, run before anything more thorough.
Flaky tests — A test that sometimes passes and sometimes fails without any change to the code it tests.

All glossary terms · Testing techniques · All 39 mock REST APIs

Last updated 16 October 2026