Sandbox environment setup

Sandbox environment setup is the setup of an isolated test environment (sandbox) of your API or product, in which external developers safely check their integration: they make requests that are real in format, get realistic responses, but do not touch production data, money or real customers. We stand up a separate isolated environment with test data, test keys and payment systems in test mode (for example, Stripe test mode), set up isolation from production, fill it with plausible examples and, if needed, a reset or re-creation of data so each partner starts from a clean slate. A sandbox is the safe backend that a playground (see the “API playgrounds” service), Postman collections and SDKs use while debugging. The point is to give integrators a safe place to try things out: to run scenarios, catch their own mistakes and make sure everything works before touching the production system. Importantly and honestly: the value of a sandbox is that it behaves close to production but is isolated (perfect parity is not guaranteed). And that is also the main difficulty: a sandbox that has fallen behind the production API in behavior is misleading — a partner debugs against it and then everything breaks in production; so it has to be kept in sync with production, and that is a process, not a one-off setup. An abandoned sandbox that has drifted from production is worse than none. Also honestly about safety: the point of a sandbox is that “Run” does not charge real money or send an email to a live person; we use test keys and fake but realistic data and check that the environments are really separated: production data does not leak into the sandbox and partner access is limited to the test environment. And about scope: a sandbox is real infrastructure (hosting, data, upkeep), so if you have no external integrators or the API only reads data (no side effects), a separate sandbox is unnecessary — test keys on staging are enough, and we will say so directly. A full sandbox is justified when the API has external consumers and dangerous operations (payments, orders, mailings) that must not be touched for real. Picture this: a new partner gets access to the sandbox, runs payments and orders in it with test cards, catches their own bugs — and goes to production already confident, without breaking a single real order. The base price starts from 80,000 ₽ for the setup; hosting and keeping the circuit in sync with production are agreed separately.

• Partners have nowhere to safely test the integration — only on the production system.
• Integrators’ tests touch real data: real orders, payments, emails to customers.
• There is nowhere to point the playground and collections — no safe backend.
• You are afraid to expose the API because “Run” could trigger real operations in production.

• A separate isolated environment (sandbox) of your API or product
• Test data — fake but realistic
• Test keys and payment systems in test mode
• Isolation from production: no real money, no emails to live people, no production data leaking into the sandbox
• If needed — a reset or re-creation of data for a clean start
• Wiring with the playground, Postman and SDKs as the safe backend
• Documentation on accessing the sandbox for partners
• Rules for keeping the sandbox in sync with the production API

• Partners test safely — the production system is untouched
• Integration is checked in advance — fewer surprises in production
• There is somewhere to point the playground, Postman and SDKs
• The API can be safely exposed — dangerous operations stay in the sandbox

• We work through the API, the dangerous operations and what should be in the sandbox
• We stand up the isolated circuit, test data, keys, payments in test mode
• We wire it to the playground and tools, document it, and agree on upkeep

• How is a sandbox different from a playground and from ordinary staging?

  A playground (see the “API playgrounds” service) is the “try it in the browser” interface, while a sandbox is the safe backend the playground hits. Staging is usually your internal environment for QA. A sandbox, in turn, is made for external partners: with test data, isolation and outside access. Often a playground and a sandbox come as a pair: one gives the “try it”, the other the safe “where”.

• Won’t the sandbox drift from the production API?

  That is the main risk, and we keep it in focus. If the sandbox falls behind production in behavior, it starts to mislead: a partner debugs against it and then it breaks in production — which is worse than if there had been no sandbox at all. So we build in an upkeep process: updating the sandbox together with the API. We do not promise a perfect match, but the gap can be kept small and visible.

• Do we definitely need a separate sandbox?

  Not always. If you have no external integrators or the API only reads data and changes nothing, a separate sandbox is unnecessary — test keys on staging are enough, and we will honestly say so. A sandbox is justified when the API goes outside and has dangerous operations — payments, orders, mailings — that partners must not be allowed to try for real.