Forem: FetchSandbox

Testing Resend's template email flow end to end

FetchSandbox — Sat, 25 Apr 2026 14:06:02 +0000

Three API calls. One template ID that has to carry through all of them.

Resend's API for sending a templated email is three steps:

Create a template
Publish the template
Send an email using that template

Each step depends on the one before it.

The template ID from step 1 has to be passed into step 2. The published status from step 2 has to be confirmed before step 3 will actually send. And if you want to verify your integration end to end, you need the template.created webhook to fire after step 1.

That is a simple flow. But most developers do not actually test it as a flow.

How most people test this

The typical approach:

Create a template in the Resend dashboard manually
Copy the template ID into your code
Call the send endpoint with that hardcoded ID
Check your inbox

That tests one thing: can your code call POST /emails with a valid template ID?

It does not test:

Whether your code correctly creates templates via the API
Whether the publish step returns the right status
Whether the template ID chains correctly from creation to sending
Whether the template.created webhook fires and your handler processes it
Whether the whole flow works when run programmatically, not manually

Hardcoding a template ID is not integration testing. It is calling one endpoint with a known parameter.

What the real flow looks like

POST /templates
  → 200: { id: "tpl_abc123", object: "template" }
  → webhook: template.created fires

POST /templates/tpl_abc123/publish
  → 200: { id: "tpl_abc123", status: "published" }
  → webhook: template.published fires

POST /emails
  → 200: { id: "email_xyz789" }
  body: { template_id: "tpl_abc123", to: "user@example.com" }

Three calls. Two webhooks. The template ID threads through every step.

The question you should be able to answer before shipping is not "does POST /emails work?" It is "does my entire template-to-send pipeline work when the template is created, published, and referenced programmatically?"

The webhook part

Most email integrations skip webhook verification entirely.

That is understandable. For a simple "send one email" integration, you might not need webhooks at all.

But once you are building a system that creates templates dynamically — onboarding flows, transactional sequences, marketing automation — you probably want to know when a template was created and when it was published.

template.created tells your system the template exists. template.published tells your system it is safe to reference in send calls.

If your code sends an email with a template that has not finished publishing, you get a confusing error that looks like a bad template ID. The actual issue is a timing problem in your flow.

Testing the webhooks is how you catch this before production.

The testing setup problem

To test this flow against real Resend, you need:

A Resend API key
A verified sender domain
A real email address to receive the test send
A webhook endpoint reachable from the internet

That is reasonable for a production integration test.

It is less reasonable for the Tuesday afternoon when you just want to know if your template creation flow works before you wire it into your app.

Running it without any of that

I built a sandbox where you can run this exact flow without a Resend API key, without a verified domain, and without hosting a webhook endpoint.

You call POST /templates. The sandbox creates a template and returns a real ID. You call POST /templates/{id}/publish. The status updates. You call POST /emails with that template ID. The send succeeds. The webhooks fire automatically between steps.

The state persists. The IDs chain. The whole flow runs in about 30 seconds.

Try the Resend template workflow

Why this matters for email integrations specifically

Email is one of those integrations where "it worked in testing" and "it works in production" can be very different things.

Templates get created but not published. Send calls reference stale template IDs. Webhook handlers assume the template exists before the creation event arrives.

These are not exotic edge cases. They are the normal bugs that happen when you test endpoints in isolation instead of testing the flow.

The fix is not complicated. Run the whole chain once, in order, with state that carries between steps. If the template ID from step 1 appears correctly in step 3, your integration probably works. If it does not, you want to find out now, not when your onboarding emails start failing.

That is what FetchSandbox does. Turns any OpenAPI spec into a stateful sandbox with workflows.

Curious how other people handle email integration testing. Do you test against real Resend with test keys, use a mock, or mostly just trust the dashboard and check your inbox?

How to test GitHub merge conflicts locally

FetchSandbox — Wed, 22 Apr 2026 04:47:25 +0000

The happy path for a pull request is boring. The merge conflict is where the integration usually gets real.

Most GitHub API demos stop too early.

They show how to open the pull request, fetch it, maybe list reviews, and then call it done.

That is useful for proving your auth works. It is not enough for proving your PR automation works.

The harder branch is the one where the pull request exists, the metadata looks fine, and then the merge step hits a conflict. That is the path that decides whether your bot, internal tool, or release workflow can recover sanely.

The small workflow that actually matters

For this kind of test, I care about a very small flow:

open the pull request
fetch the PR again to inspect its status
try the merge step
see what your system does when the PR is not cleanly mergeable

That starts with something like:

curl -X POST \
  "https://api.github.com/repos/acme-corp/api-gateway/pulls" \
  -H "Authorization: Bearer $GITHUB_TOKEN" \
  -H "Accept: application/vnd.github+json" \
  -d '{
    "title": "fix: handle nil pointer in rate limiter",
    "body": "Fixes #142. Adds nil check before accessing connection pool.",
    "head": "fix/rate-limiter-nil",
    "base": "main"
  }'

and then quickly becomes:

curl \
  "https://api.github.com/repos/acme-corp/api-gateway/pulls/<number>" \
  -H "Authorization: Bearer $GITHUB_TOKEN" \
  -H "Accept: application/vnd.github+json"

The useful part is not just that the PR exists. It is what your code does when the branch cannot merge cleanly after that.

Where teams usually get fooled

The trap is treating "pull request created" as proof that the automation is basically done.

But a lot of GitHub workflows only become interesting after creation:

the branch is stale
another change landed on main
the PR looks valid but is not mergeable
your bot tries to continue anyway
your UI says "ready" even though a human now has to intervene

That is the same pattern that shows up in a lot of async integrations: step 1 succeeds, so the app assumes the whole job is healthy.

What I would test before production

If I only had time for one narrow GitHub API test, I would test the merge-conflict branch.

I would check:

can my app detect that the PR exists but is not safely mergeable?
do I expose the right state to the user, instead of pretending it is still a normal merge path?
do retries keep hammering the same PR, or do we stop and surface the conflict clearly?
if there is a webhook or follow-up read in the flow, does the final state stay honest?

That last part matters more than the first API call.

A lot of automation bugs are not "could not create PR."

They are more like:

"we created it, then misread the later state"
"we retried the wrong step"
"we told the user merge was blocked too late"

Why this is a better test than another PR happy path

A happy-path pull request test mostly proves you can talk to GitHub.

A merge-conflict test tells you whether your integration can survive a normal repo state that changes under it.

That is a much better signal for:

release tooling
AI coding agents opening PRs
internal automation that tries to auto-merge fixes
any workflow that assumes the branch state will stay clean between creation and merge

It is also more realistic. Real repositories drift constantly. If your testing never touches the conflict branch, your merge logic is probably getting too much credit.

The part I think is underrated

The useful question is not just:

"can I create a PR through the GitHub API?"

It is:

"when the PR stops being mergeable, do I still know what happened and what to do next?"

That is the gap between endpoint testing and workflow testing.

The endpoint docs explain the request shape. The real integration job is deciding what your system should do after the branch state changes.

If you want to make this easier locally

I like testing this as a narrow workflow instead of a broad "GitHub API integration" check.

That is also why I keep a runnable GitHub docs portal on FetchSandbox around. The useful part is being able to open the PR, fetch it again, and inspect the later branch in one place instead of stopping at creation.

For me, the merge-conflict path is one of those cases where a small failure-mode test teaches more than a longer happy-path demo.

Curious how other people handle this. If your GitHub automation opens a PR and later hits a conflict, do you surface that as a first-class state, or does it still turn into log-diving and confused retries?

How to test Stripe webhook signatures locally without breaking verification

FetchSandbox — Fri, 17 Apr 2026 16:24:17 +0000

The request usually succeeds first. The signature check is where the time disappears.

Most Stripe integrations do not fail on the first API call.

You create the customer. You create the PaymentIntent. You confirm it. Everything looks fine. Then the webhook arrives and your handler says invalid signature.

That is usually the moment the debugging session starts.

The annoying part is that the failure often has nothing to do with Stripe itself. It is usually your local setup. The payload got parsed too early. The raw body changed. The signature was generated against bytes your app never saw.

One common example in Node/Express is using express.json() on the webhook route. That middleware parses and re-serializes the body, which means the bytes you verify are no longer the bytes Stripe signed.

Instead of this:

app.post("/webhooks/stripe", express.json(), (req, res) => {
  const sig = req.headers["stripe-signature"];
  const event = stripe.webhooks.constructEvent(req.body, sig, webhookSecret);
  res.sendStatus(200);
});

you usually need the raw body on that route:

app.post("/webhooks/stripe", express.raw({ type: "application/json" }), (req, res) => {
  const sig = req.headers["stripe-signature"];
  const event = stripe.webhooks.constructEvent(req.body, sig, webhookSecret);
  res.sendStatus(200);
});

The hard part is not just fixing the route once. It is trusting that the whole flow still works after the fix:

the webhook arrives
the signature verifies
your handler updates state correctly
retries do not double-process the event

That is why webhook testing feels weirdly slippery. The API call and the webhook handler are two different systems, and most local setups only make one of them easy to observe.

What to test instead of the webhook in isolation

What has helped me most is testing the full flow instead of testing the webhook in isolation:

trigger the upstream action
inspect the exact webhook payload and headers
verify the handler against the raw body
confirm the final state change after the webhook is processed

That last step matters more than most examples admit. A verified signature is good. A verified signature plus the correct final state is what actually tells you the integration works.

Why this bug sticks around

Webhook bugs are slippery because the API call and the webhook handler live on two separate timelines.

The API request can succeed immediately. The event can arrive later. Your logs for one may be clean while the other is quietly failing. That is why developers end up jumping between local tunnels, dashboard events, request logs, and app state, trying to piece together what actually happened.

The hard part is rarely "can I trigger a Stripe event?" The hard part is "can I trust the whole PaymentIntent plus webhook path enough to ship it?"

A more useful local testing setup

If you want a shortcut, use a webhook sandbox or a test environment that lets you inspect the full Stripe flow end-to-end instead of only replaying one event at a time.

The useful part is not the mock payload. It is being able to see the request, the event, and the resulting state in one place.

For Stripe-specific workflow context, this is also why a runnable Stripe portal is more useful than example requests alone.

Curious what other people use here. Do you mostly replay events, tunnel to localhost, or test the full PaymentIntent plus webhook path every time?

How to test Stripe webhook signatures locally without breaking verification

FetchSandbox — Wed, 15 Apr 2026 18:51:30 +0000

The request usually succeeds first. The signature check is where the time disappears.

Most Stripe integrations do not fail on the first API call.

You create the customer. You create the PaymentIntent. You confirm it. Everything looks fine. Then the webhook arrives and your handler says invalid signature.

That is usually the moment the debugging session starts.

Instead of this:

app.post("/webhooks/stripe", express.json(), (req, res) => {
  const sig = req.headers["stripe-signature"];
  const event = stripe.webhooks.constructEvent(req.body, sig, webhookSecret);
  res.sendStatus(200);
});

you usually need the raw body on that route:

app.post("/webhooks/stripe", express.raw({ type: "application/json" }), (req, res) => {
  const sig = req.headers["stripe-signature"];
  const event = stripe.webhooks.constructEvent(req.body, sig, webhookSecret);
  res.sendStatus(200);
});

The hard part is not just fixing the route once. It is trusting that the whole flow still works after the fix:

the webhook arrives
the signature verifies
your handler updates state correctly
retries do not double-process the event

That is why webhook testing feels weirdly slippery. The API call and the webhook handler are two different systems, and most local setups only make one of them easy to observe.

What to test instead of the webhook in isolation

What has helped me most is testing the full flow instead of testing the webhook in isolation:

trigger the upstream action
inspect the exact webhook payload and headers
verify the handler against the raw body
confirm the final state change after the webhook is processed

That last step matters more than most examples admit. A verified signature is good. A verified signature plus the correct final state is what actually tells you the integration works.

Why this bug sticks around

Webhook bugs are slippery because the API call and the webhook handler live on two separate timelines.

The hard part is rarely "can I trigger a Stripe event?" The hard part is "can I trust the whole PaymentIntent plus webhook path enough to ship it?"

A more useful local testing setup

If you want a shortcut, use a webhook sandbox or a test environment that lets you inspect the full Stripe flow end-to-end instead of only replaying one event at a time.

The useful part is not the mock payload. It is being able to see the request, the event, and the resulting state in one place.

For Stripe-specific workflow context, this is also why a runnable Stripe portal is more useful than example requests alone.

Curious what other people use here. Do you mostly replay events, tunnel to localhost, or test the full PaymentIntent plus webhook path every time?

what actually happens when you provision a phone number in twilio

FetchSandbox — Mon, 13 Apr 2026 06:06:55 +0000

i was trying to understand how twilio workflows actually behave end-to-end… not just from docs, but in practice

so i ran a simple flow:
provisioning a phone number

instead of just calling the api and stopping there, i wanted to see:

what the request looks like
what the response returns
what webhook events get triggered
what the final state looks like

here’s the full flow

what’s interesting

a few things stood out:

it’s not just request → response
webhook events are part of the flow
state changes matter just as much as the initial api call

most examples usually stop at:

“here’s the request and response”

but in real integrations, you need to care about:

when webhooks fire
how many times they fire
what state the resource ends up in

why this matters

if you’re building integrations, especially anything async:

just checking a 200 response isn’t enough

you need to understand:

how the system behaves over time
what events are emitted
how your system reacts to them

curious how others are testing this

when you integrate with twilio (or similar apis):

do you:

just rely on docs + sandbox?
simulate webhooks manually?
build your own test harness?

would love to hear how others approach this

Stop mocking APIs. Use a stateful sandbox instead.

FetchSandbox — Thu, 09 Apr 2026 12:32:56 +0000

Every developer has written this code:

// TODO: replace with real API call
const mockUser = { id: "usr_123", email: "test@test.com", status: "active" };

Then forgotten about the TODO. Then shipped it. Then found out in production that the real API returns state not status, and the ID format is user_2xAbC not usr_123.

Mocks lie. Sandboxes don't.

What if you could test against real API behavior — without production credentials?

That's what FetchSandbox does. Give it any OpenAPI spec, and it provisions a stateful sandbox in seconds:

POST /users creates a user that persists
GET /users/{id} returns it
PATCH /users/{id} with { "banned": true } updates the state
Webhook events fire on every state change
Invalid transitions return proper error codes

No mock files. No Wiremock configs. No Postman collections to maintain.

We just added 5 new APIs

This week we onboarded five APIs developers actually struggle to test:

API	Endpoints	Why it's hard to test
Clerk	196	SSO flows need a real IdP, sessions expire
Resend	83	Actually sends emails, burns through quota
Cohere	41	API credits add up, RAG pipeline iteration is expensive
Svix	128	Webhook delivery fails to localhost
Glean	79	Enterprise search needs connected data sources

Each comes with curated workflows — real multi-step integration flows you can run instantly.

How it works in 30 seconds

# 1. Create a sandbox
curl -X POST https://fetchsandbox.com/api/sandboxes \
  -H "Content-Type: application/json" \
  -d '{"spec_id":"clerk"}'

# Returns: { "id": "a1b2c3", "credentials": [{ "api_key": "sandbox_..." }] }

# 2. Use it like the real API
curl https://fetchsandbox.com/sandbox/a1b2c3/users \
  -H "Authorization: Bearer sandbox_..." \
  -H "Content-Type: application/json" \
  -d '{"email_address": ["dev@acme.com"], "first_name": "Jane"}'

# 3. State persists — fetch the user you just created
curl https://fetchsandbox.com/sandbox/a1b2c3/users/{id} \
  -H "Authorization: Bearer sandbox_..."

That's it. Real stateful behavior, proper error codes, webhook events — all from the OpenAPI spec.

The agent-ready integration guide

Here's the part that surprised us. We generate "integration guides" — Markdown files that contain:

Every verified endpoint with exact request/response shapes
State machine transitions (what can happen to a subscription after it's created?)
Webhook events that fire at each step
Sandbox credentials for testing

When you hand this to a coding agent (Claude Code, Cursor, Copilot), the agent:

Reads the guide
Inspects your existing repo patterns
Asks about scope before implementing
Builds working integration code using only verified data

No hallucinated endpoints. No invented status codes. Every fact comes from sandbox execution.

We tested this with Paddle's subscription lifecycle. The agent built a complete billing dashboard — product catalog, checkout, subscription management with activate/pause/resume/cancel — from just the integration guide.

See the code →

49 APIs, 9,300+ endpoints

The full catalog includes Stripe, Paddle, PayPal, Twilio, GitHub, OpenAI, Shopify, DigitalOcean, Datadog, and 40 more.

Every spec gets:

Automatic docs portal
Workflow discovery
Stateful sandbox
Integration guides

Browse the catalog →

What's next

We're onboarding new APIs every week. If there's an API you're struggling to test, let us know — onboarding takes minutes if you have an OpenAPI spec.

Next up: Deepgram, AssemblyAI, Stytch, Replicate, and Lago.

FetchSandbox is free to try. No signup required. Sandboxes run in your browser.

got a 200 response in minutes… still took hours to know if anything worked

FetchSandbox — Sun, 05 Apr 2026 00:05:58 +0000

i was integrating with Paddle recently

got a 200 response pretty quickly

so i thought… ok this should be straightforward

it wasn’t

not because the API was hard

but because i couldn’t tell if anything actually worked

what’s easy now

most APIs today are pretty good at getting you started

docs are cleaner
SDKs are better
you can make your first API call in minutes

that part is honestly not the problem anymore

where things slow down

the time goes after that first 200

you start asking:

did the webhook fire?
did it fire with the right payload?
did the state actually change?
is it the correct state or just “some state”?
what happens if this fails?

and there’s no single place to see this

so you jump between:

your terminal
webhook logs
dashboards
your own code

trying to figure out what actually happened

the loop

this is usually how it goes:

call API → looks fine

wait for webhook → nothing

retry → webhook shows up twice

check state → not what you expected

add logs → try again

repeat

after a few tries you’re not even sure what you’re debugging anymore

what we optimize for

most DX today is focused on:

how fast can you make your first API call

which is useful… but not enough

because calling the API is not the hard part anymore

what actually matters

what matters is:

how long it takes before you trust your integration

not “it returned 200”

but:

the system behaves the way you expect
state moves correctly
webhooks fire correctly
retries don’t break things

that’s what actually decides if you can ship

docs vs reality

docs show:

request
response
“success”

real life looks more like:

request succeeds
webhook missing
state is off
retry changes something else

and now you’re debugging across multiple places

what we started doing

after hitting this a few times, we stopped looking at just API calls

and started looking at the whole flow:

create → update → confirm
state transitions
webhook events
final result

in one place

not just:

“did it return 200”

but:

“did it actually work”

ended up building a small internal tool to run these flows end-to-end and see the final state instead of stitching logs manually

turned it into something usable here: https://fetchsandbox.com

still feels like a gap

curious how others deal with this

are teams actually measuring this properly?

or are we all still:

reading logs
retrying requests
and hoping it works in prod

Our partners kept breaking on staging. So we gave them production access. (Don't do this.)

FetchSandbox — Wed, 01 Apr 2026 23:00:29 +0000

I work on an embed platform. Partners integrate our APIs to build features into their own products — payments, identity verification, onboarding flows.

We spent six months trying to answer one question: how do partners test their integration before going live?

We tried four approaches. Each one failed in a new and exciting way.

Attempt 1: "Just use our docs"

We pointed partners to our API docs. Endpoints, auth, request/response examples. "You're good to go."

Partners would start building, hit something we didn't document, open a support ticket, wait two days, lose momentum. A few never came back. One told us they went with a competitor because "we couldn't get a working test setup in a week."

The docs described what should happen. Partners had no way to see what actually happens until they wrote code, deployed it, and hoped.

Attempt 2: Internal UAT box

Next idea: give partners access to our internal UAT environment. IP whitelisted, shared credentials. We told them "please don't break anything" without a hint of irony.

Worked for three weeks.

Then QA pushed a bad config on a Tuesday afternoon. Partner's integration broke. They didn't know it was our side — spent two days debugging their own code before opening a ticket. By the time we figured it out, their engineering lead was cc'ing our VP.

Around the same time, another team was running load tests on UAT. Partner's API calls were timing out. Their CTO emailed us asking if our platform was "production-ready."

UAT was built for us to break things. We invited external partners into that mess.

Attempt 3: Staging with IP whitelisting

We carved out a "partner staging" — same codebase, separate deployment, IP whitelisted per partner. This felt like the grown-up solution.

It wasn't.

IP whitelists were a full-time job. Every new partner meant new firewall rules. Partners working from home had different IPs than their office. One partner's CTO was traveling and couldn't hit the sandbox from his hotel. We were debugging VPN configs at 11pm on a Thursday.

Test data went stale. Partners tried to create orders for products that existed in production but not in staging. "Your API returns 404 for product_id XYZ." Yes, because nobody seeded staging in three weeks.

Deploys kept colliding. Engineers would ship to staging without checking if partners were actively testing. A deploy during a partner's live demo call is the kind of thing that gets brought up in quarterly business reviews.

Cost. Running a full mirror of production for partner testing. Database, compute, monitoring, on-call rotation. All for an environment that got used maybe 10 hours a week.

Attempt 4: Production access

I wish I was kidding.

The reasoning: "staging is flaky, UAT is a disaster, let's just whitelist them on production with read-only test accounts."

The API was stable! Partners were happy. For about a month.

Then one partner's integration bug created 400 orphaned records in production. Our data team spent a weekend cleaning it up.

Compliance wanted to know why test payloads with fake PII were hitting the production database.

When we needed to do maintenance, we had to coordinate downtime with partners who were "just running a few test calls."

We'd built the world's most expensive and dangerous sandbox: production with IP whitelisting.

What we actually needed

After burning six months on this, the answer felt obvious in hindsight. Partners didn't need access to our infrastructure at all.

They needed an API that looked and acted like ours — same endpoints, same schemas, same auth patterns — but was completely separate. Something where POST actually creates a resource, GET retrieves it, state transitions work, and nobody else's deploy can break it.

Not a mock server (those are stateless — step 2 doesn't know about step 1). Not a shared staging box (those are everybody's problem). A dedicated, isolated sandbox generated from the same OpenAPI spec our real API uses.

What I'm building now

This experience is half the reason I started working on FetchSandbox. You give it an OpenAPI spec and it spins up a stateful sandbox — real CRUD, state machines, webhook events, seed data. No infrastructure to manage.

# Partner gets a sandbox from your spec
npx fetchsandbox generate ./your-api-openapi.yaml

# They can call endpoints immediately
curl https://your-api.fetchsandbox.com/v1/orders \
  -H "api-key: sandbox_abc123"
# → 200 OK, returns realistic seed data

# They can run the full integration workflow
fetchsandbox run your-api create-and-fulfill-order
# → ✓ Create order — 201
# → ✓ Add line items — 200
# → ✓ Submit for fulfillment — 200
# → ✓ Webhook: order.fulfilled fired
# → All steps passed

No staging environment to maintain. No IP whitelists. No risk to production. Partners get their own URL, their own data, their own credentials. Your team doesn't touch it.

When a partner asks "does this workflow work?" — they prove it themselves. No support ticket needed.

The time sink nobody tracks

If you run a partner API, add up how many hours your team spends per month on:

Provisioning and maintaining test environments
Debugging "is your sandbox down?" tickets
Managing IP whitelists and VPN access
Re-seeding stale test data
Coordinating deploys around partner testing schedules

At my company it was easily 20-30 hours a month across engineering and DevOps. For a problem that shouldn't exist.

Try it

FetchSandbox works with any OpenAPI 3.x spec. 19 APIs are live — Stripe, GitHub, Twilio, WorkOS, and more. No signup.

If you run an API platform and want to try this with your own spec, reach out — @fetchsandbox on X or hello@fetchsandbox.com.

Free during early access.

I know I'm not the only one who's been through this. UAT → staging → "just give them prod." If you've found a better way to handle partner sandbox environments, I'd genuinely like to know. Still figuring this out.

This is amazing truly

FetchSandbox — Tue, 31 Mar 2026 00:53:27 +0000

Nikoloz Turazashvili (@axrisi)

Mar 26

Stop Paying for Cloud: Deploy a Highly Available Cluster on Your Own Hardware in Minutes | MicroCloud

#linux #devops #cloud #tutorial

Comments 3

4 min read

My mock server lied to me. So I built a stateful API sandbox.

FetchSandbox — Mon, 30 Mar 2026 23:26:50 +0000

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 intent for that customer (needs the customer ID from step 1)
Confirm the payment intent (needs the PI ID from step 2)
A webhook fires (your server needs to handle it)

A mock server can't do steps 2-4. The IDs don't carry over. The webhook never fires. You're testing a fantasy.

What I actually needed

I needed a sandbox where:

POST creates a real resource I can GET later
IDs chain between requests like they would in production
State transitions work (a charge goes from pending to succeeded)
Webhooks fire when things change

Basically — not a mock, but a tiny fake version of the actual API that behaves like the real thing.

So I built one

I've been heads-down on FetchSandbox for a few months now. You give it an OpenAPI spec and it generates a stateful sandbox with seed data, state machines, and webhook events.

Here's what it looks like from the terminal:

npm install -g fetchsandbox

fetchsandbox generate ./stripe-openapi.yaml
# ✓ Sandbox ready: 587 endpoints, 63 seed records

fetchsandbox run stripe --all
# ✓ Accept a payment — 3/3 steps passed
# ✓ Onboard a connected account — 3/3 steps passed
# ✓ Respond to a dispute — 2/2 steps passed
# ✓ All workflows passed — 3/3 (9ms)

That run --all command is the thing I wish I'd had. It executes every integration workflow end-to-end — creating resources, chaining IDs between steps, and verifying each response. If something breaks, you see exactly which step failed and why.

The stuff that surprised me while building it

Error scenarios were harder than happy paths. I added a --scenario flag so you can switch the whole sandbox to "auth_failure" mode and see what happens:

fetchsandbox run stripe accept_payment --scenario auth_failure
# ✗ Step 1: POST /v1/payment_intents → 401 Unauthorized
# Scenario "auth_failure" correctly caused failure.
# Scenario reset to default.

My code had a bug where it didn't handle 401 on the payment intent endpoint — only on the customer endpoint. Would never have caught that with a regular mock.

Webhooks were a rabbit hole. In a real Stripe integration, half the logic is in webhook handlers. The sandbox now fires webhook events when resources mutate, and you can watch them in real-time:

fetchsandbox webhook-listen stripe
# 12:04:31  payment_intent.created  pi_xyz  → requires_confirmation
# 12:04:32  payment_intent.succeeded pi_xyz → succeeded

Inspecting state is underrated. After running a workflow, you can see exactly what's in the sandbox:

fetchsandbox state stripe customers
# customers — 3 records
# ┌──────────────┬─────────────────┬──────────┐
# │ id           │ email           │ status   │
# ├──────────────┼─────────────────┼──────────┤
# │ cust_abc123  │ test@acme.com   │ active   │
# └──────────────┴─────────────────┴──────────┘

How it compares to the alternatives

I'm not going to pretend FetchSandbox replaces everything. Here's where I honestly think it sits:

	Mock server (Prism)	Vendor sandbox (Stripe test mode)	FetchSandbox
Setup time	1 min	15-30 min (account + keys)	< 30 sec
Stateful	No	Yes	Yes
Signup required	No	Yes	No
Works offline	Yes	No	Hosted (offline coming)
Matches prod exactly	No	Yes	No (schema-accurate, not logic-accurate)
Webhooks	No	Yes (with CLI forwarding)	Yes (built-in)
Any OpenAPI spec	Yes	Only their API	Yes

The honest gap: FetchSandbox doesn't replicate vendor-specific business logic. Stripe's test mode knows that a card ending in 4242 succeeds and 4000000000000002 declines. FetchSandbox doesn't. It validates your integration pattern, not the vendor's edge cases.

For me, that's the right tradeoff. I use FetchSandbox while building the integration, then switch to the vendor's test mode for final validation.

CI/CD is where it clicks

The thing I'm most excited about is this:

# GitHub Actions
- name: Prove integration works before deploy
  run: npx fetchsandbox run stripe --all --json

Exit code 0 = all workflows pass. Exit code 1 = something broke. Your pipeline catches integration regressions before they hit staging.

Numbers

I ran a benchmark — time from "I want to explore this API" to "I made my first successful call":

Vendor docs path: 15-30 minutes (signup → dashboard → keys → local server → SDK → code → run)
FetchSandbox path: under 1 second (open portal → endpoint is callable)

Nordic APIs defines TTFC (time to first call) benchmarks: under 2 minutes is "Champion" tier. Over 10 minutes is a "Red Flag."

Try it

19 APIs are live right now — Stripe, GitHub, Twilio, WorkOS, OpenAI, DigitalOcean, and more. No signup needed.

fetchsandbox.com

It's free during early access while I figure out what developers actually need from it. If you try it and something breaks or feels wrong, I genuinely want to know — I'm @fetchsandbox on X.

Curious what other people's testing setups look like for third-party APIs. Do you mock everything? Use vendor test modes? Some hybrid? Drop a comment — I've been deep in this problem for months and I'm still learning.