Mock a third-party API like Stripe (and replay webhooks)

Why mock an API you don't own

• Speed — no round-trip to a sandbox, no shared rate limit slowing your test suite.
• Determinism — the same customer and charge every run, so assertions don't flake.
• Failure on demand — exercise your retry, timeout and error paths without waiting for the real API to misbehave.

Model the resources you call

You don't reproduce all of Stripe — only the endpoints your code touches. An enum field pins the realistic set of statuses:

{  "resources": [{    "name": "charges",    "count": 30,    "fields": [      { "name": "id", "type": "uuid" },      { "name": "amount", "type": "integer" },      { "name": "currency", "type": "enum", "values": ["eur", "usd"] },      { "name": "status",        "type": "enum",        "values": ["succeeded", "pending", "failed"] },      { "name": "customerId", "type": "ref", "ref": "customers.id" }    ]  }]}

Simulate latency and failures (Pro)

Real payment APIs are slow and occasionally fail. Add a network profile to the project: a fixed delay before every response, and a percentage of requests that return an error status you choose — per resource and method if needed.

• A 600 ms delay on charges to test your loading states.
• 10 % of POST /charges returning 402 to test declined-card handling.

Pin an exact response (Pro)

When a test needs one precise body — a specific event, a known id — pin a frozen response for that method and path. It overrides the generated data and returns byte-for-byte what you set.

Replay webhook payloads

Store the event payloads you care about as records in an events resource, fetch one, and POST it to your own webhook handler from a test or a script. You get a versioned library of realistic events to replay on demand.