DEV Community: FetchSandbox

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.