A ProdBreak sandbox is a faithful, running model of a real API. You point your app’s SDK at it, and it behaves like the real service — stateful, with a real lifecycle, real webhooks, and real error shapes — except you can control it.

​
Packs: one per API

Each API is modeled as a pack — Stripe, Twilio, GitHub, Deck, and so on. A pack captures everything that makes that service itself:

Objects & lifecycle

The resources the API exposes and the state machine they move through — pending → succeeded, queued → running → completed, and the transitions between.

Behavior & fidelity

Which transitions emit which webhooks, the real error envelope, magic values, and the values the API returns from outside its own control. This is the hand-modeled work that makes a sandbox faithful instead of a guess.
Adding a new API means writing a new pack — not rebuilding sandbox infrastructure. That’s why the promise is “any API ever”: the modeling is per-vendor, everything around it is shared.

​
What you interact with

You don’t think about internals day to day. You install a plugin, point the vendor’s SDK at the sandbox, and drive a control handle: 
const stripe = sandbox.client();    // the pack's vendor SDK, repointed at this world
sandbox.seed(...);                  // start from a known history
sandbox.faults.arm(...);            // force an outcome
sandbox.world.trigger(...);         // fire an external cause (a webhook-producing event)
The control surface is the same for every pack. Learn it once against Stripe and it’s identical when you point at Twilio, GitHub, or your own pack.
What’s faithful vs what you control is the throughline of these concepts: the API’s own data (ids, status, timestamps) is faithful and unfakeable; the values it gets from outside its control (a balance, a transcript, a score) are yours to set. Values you control is where that line gets sharp.