Forem: FetchSandbox

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 2

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.