A vendor's own test environment is the real software: nothing can be more faithful than the thing itself, and where one exists it is the right place to test a write. It also arrives empty, expires, caps your seats, and is one account per vendor with nothing shared between them. This page is about the gap between those two sentences.
01 / What vendor sandboxes are good at
Where a vendor runs a real test environment, it is the most faithful thing you can point a client at, because it is not a replica at all. It is the vendor's own software, with the vendor's own validation, the vendor's own edge cases and the vendor's own bugs. Nothing on this page beats that, and we do not claim to.
Stripe's test mode is the model everybody has in mind, and it earns the reputation: you are in a sandbox from the moment you create an account, test objects are unreachable from live mode, the card numbers are documented, and test clocks let you advance time to watch a subscription renew. If you are testing payments, use it.
The gap is not fidelity. It is that these environments arrive empty, that each one is a separate signup with its own seats and its own expiry, and that no two of them have ever heard of each other. Stripe tells you to set up the products, customers and subscriptions you need. Slack offers a template of seven fake users in seven channels. That is where the seeding script comes from, and the seeding script is what we replace.
Atlassian developer instances
Free cloud development sites for Jira and Confluence, signed up for at go.atlassian.com/cloud-dev with no request form. Five Jira Software users, five Confluence users and one Jira Service Management agent. Atlassian states these are for development and testing only, offers no support for them, and reserves the right to delete one at any time without notice.
Slack developer sandboxes
A benefit of the Slack Developer Program: an Enterprise org environment of two or more workspaces, at no additional cost, though you must be on a paid plan or supply a payment method for identity verification. Up to ten over thirty days, two active at once, eight users and two guests each, and a six-month lifespan after which it is archived.
HubSpot developer test accounts
Up to ten free test accounts per standard HubSpot account, each with a ninety-day trial of many enterprise features. They cannot sync data with other accounts, and HubSpot expires one after ninety days with no API calls to it. The separate Enterprise standard sandbox copies your production account's settings and assets, and records only if you opt into copying 5,000 contacts.
Stripe test mode
The reference everybody cites, and deservedly. An isolated test environment you are placed in the moment you create an account, with objects that are unreachable from live mode, payments that never touch a card network, documented test card numbers, and test clocks that let you advance time to exercise a billing lifecycle.
GitHub
GitHub documents no sandbox or test tenant for its REST or GraphQL API, and its terms allow one free account per person. The one exception is narrow and worth knowing: the Marketplace billing API publishes stubbed endpoints that return hard-coded, fake data for testing. For everything else, developers test against a real account.
02 / Side by side
Every cell below describes what each approach does by definition, not what any one product happens to ship this quarter. Our column says where we lose: we are read-only, we replicate a fixed set of services rather than every API, and a pinned host never changes while the live hosts re-roll every day. Check any vendor's own docs against the sources at the foot of this page.
| Dimension | Vendor sandboxes | SandboxAPIs |
|---|---|---|
| Setup time | A signup form per vendor, then a seeding script per vendor. Slack asks for a payment method for identity verification even though the sandbox costs nothing, and Atlassian's site arrives with every Jira product installed and nothing in them. | Our winOne base URL. No signup, no verification, no seeding. Any token is accepted, so the client library you already use needs no second code path. |
| Fidelity of the API itself | Their winPerfect, by definition. It is the vendor's own software, so it has behaviour no specification describes and no replica can know about. This is their win and it is not a close one. | A replica, validated against the vendor's own published specification on every CI run. That catches everything the specification describes and nothing it gets wrong, which is a real and stated limit. |
| Data on arrival | Empty, with one partial exception. Stripe has you create the products, customers and subscriptions you need. Slack offers a template of one workspace, seven system-created fake users and seven channels. Atlassian and HubSpot document no sample data at all. | Our winFull. A simulated company with people, repositories, pull requests that argue, tickets, incidents, pipelines and dashboards, all generated over ninety days of modelled time, before you have made a single request. |
| Coherence across services | None, and structurally there cannot be. Each sandbox is an account with one vendor. HubSpot states the rule outright for its own: test accounts cannot sync data with other accounts. | Our winOne canon compiled into every service's dialect. The same incident is a Slack thread, a Jira ticket, a GitHub issue and a GitLab merge request, and both git hosts agree on the head SHA. |
| Determinism, and whether CI can rely on it | No. A sandbox is a live tenant: your last test run changed it, a teammate changed it, and the record your assertion names may not be there next month. | Our winYes. A pinned host stores no bytes, it regenerates them from a recipe, and CI proves byte-identity on every run by generating, deleting and regenerating. |
| Write support | Their winYes, and this is the other row they win outright. You can create, update and delete real objects and read them back, which is the only way to test a write path properly. | No. Every write is refused with the vendor's own status and error body naming what was attempted. If your suite asserts on the result of a write, use a vendor sandbox for that part. |
| Rate-limit and error realism | BothThe vendor's own limiter, which is the real thing, but not always the live thing: Stripe documents 100 requests a second in live mode against 25 in a sandbox, and says a sandbox is not a perfect stand-in because a charge that hits a payment gateway in live mode is mocked in a sandbox. | BothThe vendor's real header families on every response, validated against the vendor's own specification. A header lets a caller ask any host for a rate-limit, server-error, timeout or latency response on demand rather than waiting to provoke one. |
| Cost | BothFree, and that is a fair answer: Atlassian's development sites are free forever, HubSpot's test accounts are free, Slack's sandboxes carry no additional cost, and no money moves in a Stripe sandbox. The price is paid in signups, seats and the time to seed each one. | BothFree with no account at 60 requests an hour, free with a key at 600, and paid plans from $5 a month for one developer. |
| Expiry, seats and upkeep | Every one has a ceiling somewhere. Slack sandboxes have a six-month lifespan and are archived at the end of it; HubSpot expires a test account after ninety days with no API calls; Atlassian caps a development site at five Jira users and reserves the right to delete it without notice. | Our winNo expiry, no seats, no per-person account. A pinned host is registered once and frozen, and the data set behind it does not need anybody to keep it alive. |
| Works for AI-agent tests | Risky in one direction and thin in the other. An agent in a live sandbox can write, so a bad run leaves damage you have to undo; an agent in a freshly created sandbox finds almost nothing to reason about. | Our winA whole populated read surface with the worst case fixed at 403. An agent can be pointed at a company's worth of repositories, tickets and dashboards and the only thing it can break is its own run. |
03 / Run it yourself
The whole comparison in one request. This is a freshly opened terminal against a host nobody has configured, with no account, no key and no seeding step, asking a repository for its open issues.
GH=https://gh-2026-03-g6.snap.sandboxapis.dev
curl -s "$GH/repos/olympus-labs/parthenon/issues?per_page=5" \
| jq -c '.[] | {number, title, user: .user.login, comments,
labels: [.labels[].name], created_at}'{"number":85,"title":"Support a copy-as-curl button in the dashboard","user":"jason","comments":0,"labels":["enhancement"],"created_at":"2026-07-25T10:24:29Z"}
{"number":83,"title":"Question: how should the ingest worker behave when the upstream times out?","user":"icarus","comments":0,"labels":["documentation"],"created_at":"2026-07-22T14:48:56Z"}
{"number":81,"title":"Support per-tenant backpressure in the data pipeline","user":"thalia","comments":0,"labels":["enhancement"],"created_at":"2026-07-22T09:43:22Z"}
{"number":80,"title":"Login redirect loops on Safari","user":"hermes","comments":0,"labels":["bug"],"created_at":"2026-07-20T09:38:46Z"}
{"number":79,"title":"Document the key dashboard","user":"clio","comments":2,"labels":["documentation"],"created_at":"2026-07-19T11:43:04Z"}Forty-three open issues in that repository, five of them above, filed by five different people over five weeks, with labels a triage rule could act on and a thread on the last one. A vendor sandbox gives you the better API and hands you an empty one. Each of those authors is a user you can fetch, sits on a team, and shows up in the git history, which is the part a seeding script never gets to.
That host is a pinned snapshot, so those bytes are the bytes you get next year too. The live hosts re-roll daily with new activity, which is the right choice for a demo and the wrong one for an assertion. See versioning and pinning.
04 / Picking one
When to choose the other thing
Choose the vendor's sandbox
When to choose SandboxAPIs
Choose SandboxAPIs
05 / Sources
13 sources, each read on the date beside it. If one of these pages has changed since and a cell above is now wrong, that is a bug in this page: tell us and we will fix it.
Mocking and stubbing libraries
WireMock, Prism, Mockoon, MSW and Postman mock servers. They give you any endpoint you can describe. We give you 21 real ones you did not have to describe.
Record and replay
VCR, Polly.JS, Nock, Hoverfly and recording proxies. A recording is the realest data there is, right up until the API moves or your test asks for something you never recorded.
Agent twins and simulated services
Arga Labs, WonderTwin, FetchSandbox and Reqres build simulated services for agents too. Where they are better, where we are, and what each one costs.
Prove it: seven requests, both sides
A spec-derived mock of GitHub and our replica of GitHub, asked the same eight questions. Both sets of output were captured by us and both are rerunnable.