> ## Documentation Index
> Fetch the complete documentation index at: https://docs.prodbreak.com/llms.txt
> Use this file to discover all available pages before exploring further.

# What is ProdBreak

> Stateful, controllable sandbox environments for any API your app depends on — faithful to the real thing, pointed at by changing one base URL.

Your app talks to APIs you don't own — Stripe, Twilio, GitHub, OpenAI, a bank, an agent platform.
Testing against them is painful: official sandboxes are read-only or stateless, you can't force the
error cases that matter, and you can't make time pass on demand. So most teams hand-mock and quietly
drift out of sync with the real thing.

**ProdBreak** gives you a sandbox that behaves like the real API — stateful, controllable, and
faithful — that you point your app at by changing **one base URL**.

```ts theme={null}
// before — your app talks to the real vendor
const stripe = new Stripe(process.env.STRIPE_KEY);

// after — same app, same SDK, pointed at your sandbox
const stripe = new Stripe(PRODBREAK_KEY, { host: PRODBREAK_URL });
```

That's the whole integration. Your code doesn't change; only the address does.

## Works with any API

ProdBreak isn't tied to one vendor. Each API is modeled once as a **pack** — a faithful, hand-built
model of that API's objects, lifecycle, errors, and webhooks. Point your app at the pack and it
behaves like the real service.

<CardGroup cols={4}>
  <Card title="Stripe" icon="https://www.google.com/s2/favicons?domain=stripe.com&sz=128" href="/apis/stripe" />

  <Card title="Twilio" icon="https://www.google.com/s2/favicons?domain=twilio.com&sz=128" href="/apis/overview" />

  <Card title="GitHub" icon="https://www.google.com/s2/favicons?domain=github.com&sz=128" href="/apis/overview" />

  <Card title="OpenAI" icon="https://www.google.com/s2/favicons?domain=openai.com&sz=128" href="/apis/overview" />

  <Card title="Plaid" icon="https://www.google.com/s2/favicons?domain=plaid.com&sz=128" href="/apis/overview" />

  <Card title="Shopify" icon="https://www.google.com/s2/favicons?domain=shopify.com&sz=128" href="/apis/overview" />

  <Card title="Deck" icon="https://www.google.com/s2/favicons?domain=deck.co&sz=128" href="/apis/deck" />

  <Card title="…and 490 more" icon="plus" href="/apis/overview" />
</CardGroup>

<Note>
  **The promise is "any API ever."** If your app calls it over HTTP, it can have a pack. Some packs ship
  today, others are rolling out, and you can [request one](/reference/packs). The examples in these docs
  deliberately span many vendors — the control surface is identical no matter which pack you point at.
</Note>

## The three things a real sandbox has to do

<CardGroup cols={3}>
  <Card title="Stateful round-trip" icon="arrows-rotate">
    What you `POST` comes back on the `GET`. Objects have a lifecycle. The sandbox is a real little
    database that behaves like the vendor's, not a fixture that returns canned JSON.
  </Card>

  <Card title="Forced outcomes" icon="bolt">
    Make any outcome happen on demand — the `402` decline, the rate-limit, the timeout, the failed
    branch of a workflow — the cases that are painful or impossible to trigger against the real vendor.
  </Card>

  <Card title="Seeding" icon="database">
    Start from exactly the history you need. Insert objects at their final state, with deterministic,
    format-correct ids.
  </Card>
</CardGroup>

On top of those three, ProdBreak models the **hard** parts faithfully: webhooks that fall out of real
state transitions (never fired by hand), a **virtual clock** you can advance, and the values a vendor
returns from *outside its own logic* (a balance, a transcript, a score) under your control.

## Two ways to use it

The two use cases are different enough that the docs keep them separate — pick the one you're here for.

<CardGroup cols={2}>
  <Card title="In CI — as a testing library" icon="vial" href="/quickstart">
    Write integration tests in your normal framework (Jest, Vitest, pytest). A fixture hands you the
    vendor's real SDK already pointed at a fresh world, plus a control handle to seed, force outcomes,
    fire events, and advance the clock. **Deterministic, reset between tests, one world per worker.**
    Start at the [Quickstart](/quickstart), then [Testing in CI](/guides/force-an-error).
  </Card>

  <Card title="As a live sandbox" icon="server" href="/guides/staging">
    Spin up a long-lived instance and point a real app at it like a staging environment. **Same
    control surface, longer-lived state, wall-clock time.** Good for manual exploration, demos, and
    front-end work without touching the real vendor. See [Running a live
    sandbox](/guides/staging).
  </Card>
</CardGroup>

## What makes it different

ProdBreak isn't a record/replay mock or a static OpenAPI stub. The value is **behavioral fidelity**:
a hand-modeled pack per API. That's what lets you force a decline *and* have the resulting webhook, the
`GET`, and the list all agree — because they're all views of one real state transition.

It also tells you the truth about where that fidelity ends. See [How faithful is it?](/fidelity) for
exactly what we guarantee and what we don't.

<Note>
  **Status: pre-release.** These docs describe the surface as it's being built. Packs are rolling out
  vendor by vendor; examples across the docs use whichever vendor makes the point clearest, and firm up
  as each pack lands.
</Note>

Ready? [Get your first green test in under 10 minutes →](/quickstart)