My mock server lied to me. So I built a stateful API sandbox.
Last month I was integrating with a payment API. Wrote my tests against a mock server, everything passed, shipped to staging — and the whole flow broke. The mock told me POST /charges returns {"id"...

Source: DEV Community
Last month I was integrating with a payment API. Wrote my tests against a mock server, everything passed, shipped to staging — and the whole flow broke. The mock told me POST /charges returns {"id": "ch_123"}. And it does. But my code then called GET /charges/ch_123 to verify the status, and the mock returned 404. Because the mock doesn't actually store anything. Every request lives in its own universe. I lost half a day to this. And it wasn't the first time. The problem with stateless mocks I've used Prism, WireMock, Mockoon — they're solid tools. You point them at an OpenAPI spec and they generate responses. But the responses are canned. There's no memory between requests: POST /customers → 201 {"id": "cust_123"} GET /customers/cust_123 → 404 # has no idea you just created this This works fine for unit tests where you're testing your HTTP client. It falls apart the moment you have a multi-step flow. Think about how a real Stripe integration works: Create a customer Create a payment i