DEV Community: FetchSandbox

Brownfield Slack alerts: a 6-minute guided MCP run on Stripe + Resend webhooks

FetchSandbox — Wed, 27 May 2026 14:45:18 +0000

I recorded a raw ~6.5 minute screen capture of my IDE running a full FetchSandbox MCP guided flow. No polish, no voiceover script — just what happens when you ask an agent to add Slack notifications for failed payments in a repo that already has Stripe checkout, Clerk JWT verification, and Resend receipt webhooks.

The video:

YOUTUBE_URL

This post is the written version of that session, with the parts that are easier to scan in prose than in a screencast.

The ask (and why it is not a greenfield task)

Prompt:

add slack notifications for failed payments — should plug into the existing stripe + resend webhook handlers

Repo: a small Next.js 15 + FastAPI demo (stripe-checkout-demo) that had seen three prior integration sessions:

Session	What landed	Where Slack attaches
Stripe seed	`POST /create-payment-intent`, `POST /webhook`	`payment_intent.payment_failed` branch
Clerk	JWT dep, `POST /clerk-webhook` (Svix)	(out of scope for this alert)
Resend	`send_receipt()`, `POST /resend-webhook`	bounce/complaint branches + receipt try/except

Slack is the fourth layer. The agent cannot treat this like a tutorial repo with one file and one webhook. It has to find the exact lines where failures today only print().

That repo reading is why a full guided run is ~6–7 minutes in the recording — not because MCP is slow, but because brownfield integration is mostly comprehension.

What “guided” means in practice

FetchSandbox MCP does not jump straight to POST /chat.completions style codegen. The flow I used (fs-router skill) looks like:

intake → introspect repo → comprehend stack + failure surfaces → guide() routing → discovery questions → prove upstream contract → (then) propose changes

Step 1 — Introspect

The introspect script scanned the repo and returned framework hints (Next.js ^15, FastAPI backend) and SDK signals for Stripe in server/main.py. The intent string mentioned Resend too; Slack is not in the FetchSandbox brain catalog, so it never appears as a routable spec.

Step 2 — Comprehend (the load-bearing step)

The agent catalogued where alerts would attach, not a new /slack-webhook route:

Event	Today	Location
`payment_intent.payment_failed`	`print()` only	webhook handler ~L95–98
`email.bounced` / `email.complained`	`print()` + TODO	Resend handler ~L139–145
Receipt send raises (Resend SDK)	swallowed with `print()`	inside Stripe success path ~L92–94

The user named Stripe + Resend handlers. The comprehend step also flagged the receipt try/except as a third visibility gap — correct webhook hygiene (do not fail Stripe retries) but operationally invisible without something like Slack.

Step 3 — `guide()` routing

guide(intent="add slack notifications for failed payments — plug into existing stripe + resend webhook handlers...")

Result:

spec: stripe
workflow: accept_payment (Tier-1 default)
confidence: 0.85
reasoning: no slack spec; Stripe is the upstream that emits the event Slack will format

That routing is the right call, but it needs to be said plainly: FetchSandbox proves the upstream event, not the Slack POST.

Step 4 — Discovery (failures tab matters)

Multi-tab confirmation:

Question	Answer	Implies
Customer geo	US only	no 3DS scenario
Capture	Auto on confirm	`accept_payment` workflow
Failure modes	Declined card (~60s)	`payment_declined` scenario

If you skip the failures tab, you get a happy-path proof that does not exercise the webhook your Slack message cares about.

Step 5 — Proof run (and the honest limit)

Delegated to fs-prove-payments: spec=stripe, workflow=accept_payment, scenario=payment_declined.

Sandbox import reused the bundled Stripe spec with hand-curated workflows. Run result on paper: 6/6 steps passed, webhooks verified: payment_intent.created, payment_intent.succeeded.

Asked for	Got	Why
`payment_declined` → `payment_intent.payment_failed`	Terminal `succeeded`, success webhooks	Curated `accept_payment` uses a deterministic pass card; scenario hook exists in the engine but this Tier-1 workflow does not exercise it

Same class of limit as other Stripe sessions: the catalog workflow is a fast preflight, not a substitute for driving a real decline.

To prove the handler your Slack code will sit in:

Method	What it proves
`stripe listen --forward-to localhost:8000/webhook` + card `4000000000000002`	Full PI flow → `payment_intent.payment_failed` at your handler
`stripe trigger payment_intent.payment_failed`	Fast iteration on Slack message template from a realistic payload

What the agent got right without me asking

Five things worth stealing for your own brownfield prompts:

No new endpoint — side effects only at existing handler lines.
Third target surfaced — receipt-send swallow, not only the two webhooks the user named.
Routing limitation named — upstream Stripe proof, Slack downstream on you.
Idempotency applied to Slack — Stripe retries on 5xx; use pi.id as dedupe key for duplicate alerts.
Resend proof deferred — one workflow per delegation; bounce/complaint shapes need a separate Resend run.

What was not done in this recording

No Slack diff applied yet (proof handed back; propose-changes step not shown in the artifact).
No Resend proof run for email.bounced / email.complained.
No Slack spec proof (none in catalog).

Expected next moves from the session:

Propose payment_intent.payment_failed → Slack at L95–98 (SLACK_WEBHOOK_URL env).
stripe trigger payment_intent.payment_failed before editing message text.
Separate Resend proof for bounce/complaint templates.
Ship payment-failed path first; Resend alerts in a follow-up PR.

MCP setup (unchanged from shorter demos)

{
  "mcpServers": {
    "fetchsandbox": {
      "command": "npx",
      "args": ["-y", "fetchsandbox-mcp"]
    }
  }
}

Cursor: ~/.cursor/mcp.json, restart IDE, enable server in Settings → MCP.

Optional skills:

curl -sL https://fetchsandbox.com/skills/install.sh | bash

The takeaway

Docs tell your agent what should happen. Runnable workflows tell it what did happen in a sandbox — and brownfield comprehend tells it where your code already handles failures.

For Slack-on-Stripe, the valuable proof is not “can we call chat.postMessage” in FetchSandbox. It is: when payment_intent.payment_failed arrives, does your handler have the fields you need for an alert, and have you tested that path with a real or triggered event?

Try FetchSandbox: https://fetchsandbox.com

Stripe workflows: https://fetchsandbox.com/docs/stripe

Watch the raw demo: https://youtu.be/AB36LXwfoTQ

If you have done brownfield API work with agents, I am curious: should the default flow always map existing handlers before any proof run, or do you prefer prove-first on greenfield repos?

Test Resend webhook reconciliation before production

FetchSandbox — Fri, 22 May 2026 03:59:54 +0000

I was trying the Resend API for a small product flow, and the first POST /emails call was not the part that worried me most.

That call gives you an email ID.

The part I care about is what happens later, when events come back:

email.delivered
email.bounced
email.opened

Resend has docs for these webhook events:

email.delivered: https://resend.com/docs/webhooks/emails/delivered
email.bounced: https://resend.com/docs/webhooks/emails/bounced
email.opened: https://resend.com/docs/webhooks/emails/opened

The docs are useful. But the integration question is not just "what fields are in the payload?"

The real question is:

can my app map this event back to the right email record?

The small bug that becomes annoying later

Most apps do something like this when sending email:

create internal notification record
send email with Resend
store resend email id
wait for webhook events
update notification status

Simple enough.

But the webhook arrives later, outside the request that sent the email.

So now your app needs to answer a few things correctly:

which internal record owns this Resend email ID?
should email.opened change the same status as email.delivered?
what happens if email.bounced arrives after you already marked the email as sent?
do you store the raw event payload for debugging?
can you replay the event without creating duplicate state changes?

None of this is hard in theory.

It is just easy to skip until production.

Testing only the send call is not enough

If you test only this:

POST /emails

you have proven that Resend accepted the request.

You have not proven your app can handle the lifecycle around that request.

For a real product, I want to test this chain:

send email
store provider email id
receive delivered event
update internal status
receive opened or bounced event
reconcile final state

That is the integration.

The endpoint is just one step inside it.

Why this is awkward to test early

To test this against the real provider path, you usually need:

Resend API key
verified sender domain
public webhook endpoint
local tunnel
event logging
test recipient
some app state to update

That setup is reasonable before production.

But when I am still exploring the API, I do not want to create all of that just to understand whether the workflow makes sense.

I want to run the shape of the workflow first.

The workflow I wanted from my IDE

At that point I wanted Cursor or Claude to run a small workflow for me:

send test email
capture email id
simulate delivered event
simulate opened or bounced event
verify app-facing state
show what changed

I tried this through FetchSandbox MCP because it gives the agent a runnable API workflow instead of only docs to read.

This is not replacing Resend's real environment. I would still need the real API key, real domain, production webhook endpoint, and provider limits before shipping.

The point is earlier than that.

Before wiring the real app, I wanted the agent to understand the lifecycle:

request -> provider id -> webhook event -> internal state

What made the validation useful

What helped was not a fake "success" message.

It was seeing a small report closer to:

PASS POST /emails returned email id
PASS internal record stored provider id
PASS email.delivered event matched provider id
PASS notification status changed to delivered
PASS email.opened event was recorded without duplicating the send

Or if it fails:

FAIL webhook event could not be matched to an internal record

That is the kind of failure I would rather see before production, not after users are asking why they never got an email.

Try the workflow

If you are exploring Resend, this is the workflow page I used:

https://fetchsandbox.com/docs/resend

From an MCP client like Cursor or Claude, the ask is simple:

validate resend email workflow with fetchsandbox

The workflow should not stop at POST /emails -> 200.

It should prove the lifecycle after the send call makes sense.

That is where most integration bugs hide.

Run APIs before setup

FetchSandbox — Wed, 20 May 2026 16:04:53 +0000

When I start integrating a new API, I do not want the first hour to be setup.

I usually want to answer a simpler question first:

how does this workflow actually behave?

That sounds obvious, but most API exploration still starts with a lot of prep:

create an account
find or generate credentials
set local environment variables
copy a curl command
send one request
copy an ID from the response
paste it into the next request
check the provider dashboard
repeat

That is fine when you already know the API.

It is slow when you are still trying to understand the integration.

The first thing I want is the workflow

When I evaluate an API, the first request is rarely the full story.

I want to know:

what should I create?
what comes back?
which ID matters?
what state changes after the request?
what webhook or follow-up event should I expect?
how do I know the workflow is actually complete?

Postman or curl can tell me whether one request returned 200.

But real integration work usually looks more like:

choose API
run workflow
inspect response
follow state
verify final result

That is the part I want to make runnable before setup.

What I am building

I am working on FetchSandbox MCP so developers can explore API workflows from their IDE.

The goal is simple:

choose an API
ask Cursor or Claude to run the workflow
see the verified result

No local env first.

No mock server stitching first.

No copy-pasting IDs between five tabs just to understand the happy path.

This is not meant to replace the real provider environment. Before shipping, you still need real credentials, real limits, production auth, webhook endpoints, monitoring, and all the normal engineering work.

But before that, developers should be able to explore the workflow quickly.

Especially now that coding agents are helping write integration code.

Docs tell the agent what should happen.

Runnable workflows let the agent prove what happened.

That is the gap I keep seeing with APIs.

The setup matters.

But the workflow should come first.

Testing Resend is not just POST /emails

FetchSandbox — Tue, 19 May 2026 13:25:37 +0000

I was trying to integrate Resend like an end user would.

The first call was straightforward.

POST /emails

You send the payload, get a 200, and now you have an email id.

That part is not where most of the integration doubt comes from. The real questions start right after it:

did it actually deliver?
did it bounce?
what events came back?
how do I update my app state from those events?
can I test that flow before wiring a real production setup?

Usually to experience all of that, you need more than just an API key. You need a domain, webhook endpoint, local tunnel, test users, event logs, and some way to replay or inspect what happened.

That is a lot of setup just to understand the shape of the integration.

The first request is not the workflow

A successful POST /emails only proves one thing: the API accepted the request.

It does not prove your app understands the lifecycle around that email.

For an email workflow, I want to see something closer to this:

send email
check response
get delivery status
trigger delivered/open/bounce events
verify final state

That is the part I wanted to run quickly from my IDE, while I was still exploring the API.

Not after creating a full app. Not after configuring a real webhook route. Just enough workflow context to understand what needs to happen.

Running the Resend workflow from Claude or Cursor

I added a Resend workflow to FetchSandbox MCP so I could ask my IDE to validate the flow directly.

Install once:

npm i -g fetchsandbox-mcp

Then from Claude, Cursor, Codex, or any MCP client, ask something like:

validate resend with fetchsandbox

The useful output is not just a fake success response. It is a small validation report:

COMPLETE Send a transactional email

✓ Send email
  POST /emails -> 200

✓ Get email status
  GET /emails/{id} -> 200

✓ Webhook verification
  email.sent -> email.delivered

That gives you a quick feel for the Resend workflow before you wire the real app.

Why this helped me

When I am integrating a new API, docs and SDK examples are helpful, but they usually stop at the first successful request.

For email, payment, auth, calendar, CRM, and webhook-heavy APIs, that is not enough. The pain is usually in the next few steps.

The endpoint works, but the product question is still open:

can my app handle the full state change?

That is why I like running provider workflows as acceptance checks from the IDE. It gives the agent a concrete path to execute instead of guessing from docs.

For Resend, the workflow is simple on purpose:

send an email
inspect the response
check status
simulate the events that matter
verify the final state

Small loop, but it answers the thing I actually care about before production.

Try it

The Resend workflow page is here:

https://fetchsandbox.com/docs/resend

If you are exploring Resend from a greenfield app, try running the workflow from Claude or Cursor first. It is a faster way to understand what your app needs to handle after POST /emails returns 200.

Not replacing Resend's real sandbox or production setup. Just a quicker loop before you commit wiring, webhooks, and state handling.

Runnable API integration workflows from your favorite IDE

FetchSandbox — Thu, 14 May 2026 13:05:00 +0000

AI coding agents are getting good at reading docs and writing integration code.

But API integrations still fail in the workflow.

create resource -> confirm state -> receive webhook -> fetch final state -> handle failure

That is why I have been building FetchSandbox MCP: runnable API integration workflows from your favorite IDE.

The goal is simple. If you are already working in Claude, Cursor, Codex, Continue, or another MCP-compatible IDE, your agent should be able to run the API workflow while it is helping you integrate it.

Not just read the docs.

Run the workflow.

Inspect the response.

Check the state transition.

Verify the webhook behavior.

Then use that proof while changing your app.

Here is the raw demo:

https://www.youtube.com/watch?v=Iafkt01GAbA

What you configure

FetchSandbox MCP runs as a local MCP server using npx.

For Claude Desktop, add this to:

~/Library/Application Support/Claude/claude_desktop_config.json

For Cursor, add this to:

~/.cursor/mcp.json

For Claude Code, use:

~/.claude/settings.json

or a project-level .mcp.json.

The config is the same basic shape:

{
  "mcpServers": {
    "fetchsandbox": {
      "command": "npx",
      "args": ["-y", "fetchsandbox-mcp"]
    }
  }
}

After adding it, restart your IDE. In Cursor, also enable the new fetchsandbox MCP server in Settings -> MCP Servers.

You can also install FetchSandbox trigger-phrase skills:

curl -sL https://fetchsandbox.com/skills/install.sh | bash

Then your IDE can respond to phrases like:

validate this integration with fetchsandbox
fs validate
check api integration coverage
validate my stripe integration

What you can ask your IDE

Once the MCP server is connected, you can ask practical integration questions, not just documentation questions.

For an existing app:

Use FetchSandbox to validate this Stripe integration. Run the available workflows, compare the expected terminal state and webhook events, then tell me what code paths in this repo need changes.

For a new integration:

I want to add a Stripe payment flow to this app. Use FetchSandbox to discover the runnable workflows first, then guide the implementation step by step.

For debugging:

Run the checkout/payment workflow in FetchSandbox and inspect the failing step. Compare the expected response, state transition, and webhook events with my current implementation.

For coverage:

Check API integration coverage with FetchSandbox and write a markdown report I can commit to this PR.

That last flow is important. The agent can produce a local artifact like:

.fetchsandbox/validation-<date>.md

with workflow results, step traces, acceptance criteria, terminal states, required webhook events, and invariants.

Why this is different from a mock server

A mock server can answer a request.

A guided workflow answers a better question:

Did the integration behavior actually work end to end?

For example, a payment workflow is not just POST /payment_intents.

It is closer to:

create customer
create payment intent
confirm payment
capture payment
verify webhook
retrieve final state

If your agent only sees endpoint examples, it can still generate code that compiles but misses the lifecycle.

If your agent can run the workflow, it has execution context.

Where FetchSandbox fits

FetchSandbox turns OpenAPI specs into:

stateful sandboxes
realistic seed data
lifecycle state machines
auth simulation
guided workflow runners
webhook behavior
generated developer portals
MCP tools for IDE agents

The point is not to replace final provider sandbox testing.

The point is to give developers and agents a fast preflight loop while the integration is being built.

Your agent can ask:

what workflows exist?
run this workflow
what state changed?
which webhook was expected?
what failed?
what should I change in the app?

That is the developer experience I want: guided API integration workflows from the IDE you already use.

Try FetchSandbox:

https://fetchsandbox.com

Watch the demo:

https://www.youtube.com/watch?v=Iafkt01GAbA

If you build API integrations, I would love feedback on the developer flow: should agents be able to run guided API workflows directly from the IDE?

Test Cal.com booking flows without calendar chaos

FetchSandbox — Tue, 12 May 2026 13:45:00 +0000

Scheduling integrations do not usually break on the first request.

They break after the booking exists.

The user gets an email. The host has Google Calendar connected. Your app sends its own ICS file. Then somebody reschedules or cancels and suddenly there are two calendar events, or one event refuses to disappear.

That is not a generic "calendar APIs are hard" problem.

It is a workflow identity problem.

The specific workflow

The narrow Cal.com flow I care about is:

Get available slots
Create a booking
Fetch the booking
Reschedule it
Cancel it
Verify the calendar and webhook side effects still point at the same booking

In API terms, the happy path looks like this:

GET  /v2/slots
POST /v2/bookings
GET  /v2/bookings/{bookingUid}
POST /v2/bookings/{bookingUid}/reschedule
POST /v2/bookings/{bookingUid}/cancel

That is the test.

Not just "can I create a booking?"

The real question is:

slot -> booking -> calendar event -> reschedule -> cancel

Do all of those still refer to the same thing?

The bug shape

Here is the kind of bug this flow catches.

Your app creates a booking through Cal.com. The attendee has a connected Google Calendar. Cal.com syncs the event into Google.

But your app also sends custom emails with its own ICS attachment.

If the ICS UID from the Booking API and the synced Google Calendar event identity do not line up, the user can end up with two events:

event from Cal.com sync
event from your custom ICS invite

Then cancellation gets messy because your app cancels one identity while the other one remains in the calendar.

This is the kind of integration bug that is easy to miss if you only test POST /bookings in isolation.

What I would assert

For a scheduling API, I want the test to preserve identity across the whole lifecycle.

The assertions should be closer to this:

booking created -> booking uid exists
calendar reference exists -> external event id is attached
reschedule uses same booking identity
cancel removes or updates the same calendar event
webhook events describe the same lifecycle

And if your product sends custom ICS files, there is one extra check:

Booking API iCalUID matches the calendar event your user will update/cancel

That last part is where teams usually learn the hard way that a "successful booking" does not mean a safe scheduling integration.

Why static mocks miss it

A static mock can return:

POST /bookings -> 201

That is not enough.

It cannot easily prove that a later reschedule call still points at the booking created two steps earlier. It cannot prove that your cancellation code is updating the same calendar event your invite email created. It cannot prove that webhook handlers and calendar references agree about the booking identity.

The state between calls is the product.

Where FetchSandbox fits

FetchSandbox has a Cal.com sandbox flow for the booking lifecycle:

https://fetchsandbox.com/cal-com/test-booking-lifecycle-locally

The broader Cal.com sandbox is here:

https://fetchsandbox.com/cal-com

The workflow is intentionally narrow because that is where integration bugs hide: slots, booking creation, booking lookup, reschedule, cancel, and the events around those changes.

You can also connect your IDE to FetchSandbox through MCP:

{
  "mcpServers": {
    "fetchsandbox": {
      "command": "npx",
      "args": ["-y", "fetchsandbox-mcp"]
    }
  }
}

Then ask an agent something like:

Use FetchSandbox MCP to run the Cal.com booking lifecycle workflow.
Explain which identifiers my app should preserve across create, reschedule, cancel, and calendar sync.

That is the direction I think API testing should move:

not just docs,
not just static responses,
but runnable workflow behavior from inside the developer's own environment.

For Cal.com-style integrations, the useful question is simple:

Can my app create, move, and cancel a booking without leaving calendar ghosts behind?

That should be testable before production users find it.

Test Notion database queries without a workspace

FetchSandbox — Mon, 11 May 2026 23:44:45 +0000

Testing a Notion database query sounds simple until you try to do it in a real workspace.

You need a workspace. You need an integration token. You need to share the right database with that integration. You need seed pages with the right properties. Then you run the query and hope you did not pollute somebody's actual team dashboard with test rows.

The painful part is not POST /v1/databases/{database_id}/query.

The painful part is proving the whole shape around it:

does the database exist?
do the properties match what your app expects?
does the filter return the right rows?
does the response shape match the code path you are about to ship?
can you repeat the test without cleaning up a real Notion workspace?

The specific workflow

The narrow workflow I care about here is:

Retrieve a Notion database
Query that database for high-priority in-progress tasks
Verify the returned page shape before wiring it into an app

In FetchSandbox, the workflow is intentionally small:

GET  /v1/databases/db-a1b2c3d4-e5f6-7890-abcd-ef1234567890
POST /v1/databases/db-a1b2c3d4-e5f6-7890-abcd-ef1234567890/query

The query body filters by two properties:

{
  "filter": {
    "and": [
      {
        "property": "Status",
        "select": {
          "equals": "In Progress"
        }
      },
      {
        "property": "Priority",
        "select": {
          "equals": "High"
        }
      }
    ]
  }
}

That is the kind of test I want before touching production code.

Not "does the endpoint return 200?"

More like:

database exists -> properties match -> filter runs -> rows come back -> app can trust the shape

Why docs and mocks miss this

Docs usually show the endpoint and a sample payload.

That helps, but it does not answer the messy integration questions:

what happens when the database is missing?
what if the integration does not have access?
what if the property name is different from the sample?
what if the query returns zero pages?
what fields should my app treat as stable?

Generic mocks usually miss this too because they return static JSON. They do not behave like a workspace with pages, databases, users, blocks, comments, and state.

For a Notion integration, state matters.

If your app reads tasks from Notion, the test needs to prove more than the request syntax. It needs to prove that your app can survive the workspace shape it expects.

How I would test it

For this workflow, I would test three cases:

1. Happy path

The database exists and contains matching pages.

Expected result:

GET database -> 200
POST query -> 200
matching pages returned

This proves the app can read the expected database shape.

2. Permission denied

The database exists, but the integration should not be allowed to read it.

Expected result:

POST query -> 403
app shows setup guidance instead of crashing

This is the case most teams discover only after connecting a real workspace with incomplete permissions.

3. Empty result

The query is valid, but no pages match Status = In Progress and Priority = High.

Expected result:

POST query -> 200
results: []
app shows an empty state

This catches a surprising number of UI and sync bugs.

Where FetchSandbox fits

This is the kind of workflow a stateful API sandbox should prove.

With the Notion sandbox in FetchSandbox, you can test pages, databases, blocks, users, comments, and search without setting up a real workspace or using a real integration token.

I recorded a raw walkthrough of this Notion database workflow here:

https://youtube.com/watch?v=xJpJ5dOR_Co

The more interesting path is connecting your IDE to it.

FetchSandbox MCP lets Cursor, Claude, or another MCP-capable agent discover and run these workflows from your own development environment:

{
  "mcpServers": {
    "fetchsandbox": {
      "command": "npx",
      "args": ["-y", "fetchsandbox-mcp"]
    }
  }
}

Then you can ask the agent something like:

Use FetchSandbox MCP to explore the Notion sandbox.
Run the database query workflow and explain what response shape my app should handle.

That changes the workflow from "read docs and copy examples" to "run the integration behavior from inside the IDE."

The Notion portal is here:

https://fetchsandbox.com/docs/notion

And the Notion landing page is here:

https://fetchsandbox.com/notion

The goal is not to replace Notion.

The goal is to give developers a runnable place to understand the API lifecycle before they wire it into a real customer workspace.

For this one workflow, the question is simple:

Can my app query a Notion database and handle the response shape correctly?

That should be testable before production.

When your SaaS API has docs but no real sandbox

FetchSandbox — Fri, 08 May 2026 18:43:53 +0000

A lot of small SaaS APIs have decent docs.

Some even have an OpenAPI spec.

But no real sandbox.

That sounds fine until a developer tries to integrate the API and needs to test the part that docs cannot prove:

Does the workflow actually hold together?

Not one request.

The workflow.

The problem is not the first 200

Most API docs can show this:

POST /customers
→ 201 Created

That is useful, but it is not enough.

For a real SaaS integration, the next questions are usually:

Can I read the same customer back?
Does the subscription attach to the right customer?
Does the webhook fire?
Does my app know which user should get access?
What happens when the subscription is canceled?

This is where a docs-only API starts to feel thin.

The integration does not fail because the endpoint is unknown.

It fails because the lifecycle is not testable.

The workflow small SaaS teams should expose

If I were building a small SaaS API, the first sandbox workflow I would expose is boring:

POST /customers
  → create a customer

GET /customers/{id}
  → verify the customer exists

POST /subscriptions
  → attach a plan to that customer

GET /subscriptions/{id}
  → verify state is active or trialing

webhook: subscription.created
  → let the developer test access control

PATCH /subscriptions/{id}
  → cancel or pause

webhook: subscription.canceled
  → verify access gets removed

That workflow is not flashy.

But it answers the question every integration needs to answer:

Can my app keep its local state aligned with the API provider's state?

Why examples are not enough

Example responses are static.

They can show what a customer looks like:

{
  "id": "cus_123",
  "email": "buyer@example.com"
}

But they cannot prove the next request will remember it.

They cannot prove a subscription belongs to that customer.

They cannot prove the webhook event is shaped the same way as the API response.

They cannot prove your app removes access when the subscription changes.

That is not a docs problem. Docs are still needed.

It is a sandbox problem.

The failure mode

The most common failure is not dramatic.

It looks like this:

customer create works
subscription create works
webhook handler returns 200

Then two weeks later:

paid customer has no access
canceled customer still has access
support cannot map billing ID to app user
webhook retry created duplicate state

All the individual calls looked fine.

The workflow was never tested.

Why small SaaS APIs skip sandboxes

I understand why this happens.

A small SaaS team is usually trying to ship the core product first.

Building a second environment with fake accounts, seeded data, fake billing states, webhook retries, and lifecycle transitions is a lot of work.

So the API ships with:

docs
examples
maybe an OpenAPI file
maybe test credentials
maybe a staging workspace if you ask support

That helps.

But for developers integrating your API, the missing piece is still the same:

Can I safely run the lifecycle before touching production?

A better minimum sandbox

The minimum useful sandbox does not need to simulate your whole company.

It only needs to simulate the workflow developers are scared to test in production.

For a SaaS API, that might be:

customer → subscription → webhook → access change

For an email API:

template → send → delivered/bounced webhook

For a CRM API:

lead → contact → deal → status webhook

For a CI API:

pipeline → workflow → job → failed/rerun

The pattern is the same:

State has to move.

The next request has to see the previous request.

The webhook has to match the state change.

How I am thinking about this in FetchSandbox

This is one of the reasons I am building FetchSandbox around workflows, not just endpoints.

An OpenAPI spec can tell you:

POST /customers exists

But an integration needs to know:

POST /customers
GET /customers/{id}
POST /subscriptions
webhook subscription.created
PATCH /subscriptions/{id}
webhook subscription.canceled

That is the difference between an endpoint mock and an integration sandbox.

For small SaaS teams, I think this could be a lightweight way to give developers something close to a sandbox without building a full second production environment.

Start with one scary workflow.

Make it stateful.

Fire the webhook.

Let developers break it safely.

That is already much better than docs alone.

FetchSandbox is where I am testing this idea: turn an OpenAPI spec into a stateful sandbox with workflows developers can run before production.

Polar external_id reconciliation: the customer field that keeps checkout tied to your user

FetchSandbox — Thu, 07 May 2026 17:57:02 +0000

Checkout is not where a billing integration starts.

For a SaaS app, it usually starts one step earlier:

Can this billing customer be tied back to the right user in my app?

That tiny mapping is easy to ignore when you are just trying to get checkout working. But later, when a webhook comes in, or a subscription changes, or support asks why someone paid but still has no access, this is the field you wish you tested earlier.

In Polar, that mapping can live in customer metadata / external customer identifiers like external_id.

The bug is not dramatic

The bug usually looks boring.

Your app creates a customer:

POST /v1/customers/

You get back a Polar customer ID.

Then later your app receives something like:

customer.created
subscription.active
order.paid
benefit.granted

Now your code has to answer one question:

Which local user does this belong to?

If you only stored the provider customer ID, you can probably make it work. But if your local user ID never made it into the customer record, or your webhook handler assumes the mapping exists before it actually does, the access-control code gets messy fast.

That is where a field like external_id matters.

It is not just extra metadata. It is the bridge between billing state and product state.

The small workflow I want to test

Before touching hosted checkout, I want this workflow to pass:

POST /v1/customers/
  email: buyer@example.com
  name: Test Buyer
  external_id: user_123

GET /v1/customers/{id}
  verify id exists
  verify email survived
  verify external_id is still user_123

customer.created
  verify webhook can be reconciled back to user_123

That is it.

No payment.
No subscription access yet.
No real customer.

Just proving that the customer record your app creates can be read back and matched to the user who started the flow.

Why this catches real billing bugs

Most checkout demos focus on the happy path:

click checkout
pay
redirect back
unlock access

But production systems depend on slower, less visible steps.

Your webhook might arrive before your app finishes saving local state. Your user may open checkout in one tab and close it. A retry may deliver the same event twice. Your support tooling may need to search by internal user ID, not provider ID.

If the customer mapping is weak, all of those paths become harder.

The failure usually shows up as:

user paid but access is not granted
webhook event cannot find a local user
customer exists in Polar, but your app has no clean link to it
support sees a billing ID but cannot connect it to an account
tests pass because they only checked 201 Created

The endpoint returned success. The integration still does not know who owns the customer.

Why a static mock is not enough

A static mock can return this:

{
  "id": "cus_test_123",
  "email": "buyer@example.com",
  "external_id": "user_123"
}

But the next request is the important one.

If you call:

GET /v1/customers/cus_test_123

does the mock remember the customer you just created?

Does it preserve external_id?

Can your webhook handler use that same value to reconcile the event?

For billing integrations, state matters more than the first response. A fake 201 is not enough.

Testing it in FetchSandbox

We added Polar to FetchSandbox so this kind of pre-checkout state can be tested without a Polar token.

The useful test is not "can I call the endpoint?"

It is:

POST /v1/customers/
GET  /v1/customers/{id}
inspect customer.created

Then check whether the same customer state flows through each step.

That gives you a simple confidence check before wiring checkout, subscriptions, orders, and benefits.

It does not replace Polar's real sandbox. You still need that before launch for hosted checkout, real signatures, account configuration, and final payment behavior.

But it helps catch the boring mapping problem earlier.

And boring mapping problems are exactly the ones that become painful after someone pays.

Try the Polar sandbox — no Polar token needed.

Curious how others handle this. Do you store provider customer IDs only, or always write your internal user ID into the billing customer too?

Test Polar's customer and product API flow without an API token

FetchSandbox — Tue, 05 May 2026 14:08:40 +0000

Polar billing integrations do not start at checkout.

The first real question is usually simpler:

Can my app create the customer and product records it will depend on later?

If that part is shaky, checkout and subscription handling get harder to trust. You end up debugging billing logic when the actual bug was earlier: the customer ID did not persist, the product did not show up in the list call, or your app stored an internal user ID that never made it into the billing system.

The boring part is the important part

Polar's API has the objects you expect in a modern billing system:

customers
products
checkouts
orders
subscriptions
benefits
webhooks

The checkout flow is the part everyone thinks about. But checkout depends on earlier state.

For example, a product has to exist before you can sell it. A customer has to map back to your own user model before you can reconcile access later. Polar supports this through fields like external_id / external customer IDs, which are exactly the sort of small integration detail that becomes painful if you do not test it early.

The first workflow to prove

The first Polar workflow I want to trust is not payment. It is state.

POST /v1/customers/
  → create a customer with email, name, external_id
  → customer.created webhook fires

GET /v1/customers/{id}
  → read the same customer back
  → verify the ID and external_id survived

And for products:

POST /v1/products/
  → create a product with price data
  → product.created webhook fires

GET /v1/products/
  → verify the product appears in the catalog list

That is not a flashy workflow. It is the foundation.

If your app cannot round-trip customer and product state, you do not have a billing integration yet. You have a few API calls that happened to return 201.

Why mocks are weak here

A static mock can return:

{ "id": "cus_123", "email": "test-buyer@example.com" }

But the next request is where the truth shows up.

If you call GET /v1/customers/cus_123, does the mock know about the customer you just created? Does it preserve your external_id? Does the list endpoint include the product you created one step earlier?

Most mocks do not. Every request lives alone.

For billing APIs, that is a bad tradeoff because the whole integration is stateful. Customers, products, checkouts, orders, subscriptions, and benefits are related. Your code is not just calling endpoints. It is moving through a lifecycle.

Testing Polar in FetchSandbox

We onboarded Polar into FetchSandbox today.

The current sandbox includes:

Polar OpenAPI spec support
seeded customers, products, and subscriptions
stateful customer creation and read-back
stateful product creation and list verification
webhook events like customer.created and product.created
subscription states like active, past_due, canceled, revoked, trialing

You can run the customer workflow without a Polar token, without creating a Polar organization, and without touching real payment state:

POST /v1/customers/
GET  /v1/customers/{id}

Or test product creation:

POST /v1/products/
GET  /v1/products/

The useful part is not that the first call returns a successful response. The useful part is that the second call can prove the first one changed state.

What this catches early

This kind of preflight catches boring bugs before they become billing bugs:

your app loses the billing customer ID
external_id does not map cleanly back to your user
product creation succeeds but your catalog query does not find it
your webhook handler assumes a customer exists before the create event is processed
your tests only check status codes, not persisted state

None of these are dramatic. They are just the kind of bugs that waste an afternoon once checkout and subscriptions are already wired.

Where the real Polar sandbox still matters

This is not a replacement for testing against Polar's own sandbox before launch.

You still want the real environment for final payment behavior, account-specific configuration, hosted checkout, signatures, and anything that depends on Polar's production logic.

The point is earlier than that.

Before you do final validation, you should be able to prove your app understands the basic lifecycle:

Create billing object
Store returned ID
Read it back
React to the webhook
Keep your local state aligned

That is the layer FetchSandbox is good at.

Try the Polar sandbox — no Polar token needed.

Curious how other teams test billing integrations before real payment flows. Do you start with the provider sandbox immediately, or do you preflight the API state first?

How to test Twilio message delivery failures locally

FetchSandbox — Fri, 01 May 2026 13:48:32 +0000

Twilio usually gives you the first 201 before it gives you the real problem.

That is what makes SMS bugs annoying.

You call the Messages API. Twilio accepts it. You get a SID back. Your app marks the notification as "sent" and everybody moves on.

Then the message never arrives.

Sometimes the destination number is bad. Sometimes the carrier rejects it. Sometimes the message moves through queued or sent and then lands in undelivered. The first API call still looked fine, so the debugging starts late.

That is the part I think a lot of Twilio examples skip. The useful test is not just "can I POST /Messages.json?" The useful test is "what does my app do after Twilio accepts the message but delivery goes sideways?"

The narrow workflow that matters

For local testing, the flow I care about is very small:

send the message
fetch the message again by SID
check what status your app sees next
confirm your retry, alerting, or customer-facing state does not pretend the message was delivered

In Twilio terms, that usually starts here:

curl -X POST \
  "https://api.twilio.com/2010-04-01/Accounts/AC.../Messages.json" \
  --data-urlencode "To=+14155551234" \
  --data-urlencode "From=+15017122661" \
  --data-urlencode "Body=Your order has shipped" \
  -u "$TWILIO_ACCOUNT_SID:$TWILIO_AUTH_TOKEN"

and then immediately becomes:

curl \
  "https://api.twilio.com/2010-04-01/Accounts/AC.../Messages/<message_sid>.json" \
  -u "$TWILIO_ACCOUNT_SID:$TWILIO_AUTH_TOKEN"

That second read is where the truth starts showing up.

Where teams usually fool themselves

The easy mistake is treating 201 Created as success for the whole job.

It is only success for the first step: Twilio accepted your request and created a message resource. It is not proof that the carrier accepted it, not proof that the handset got it, and definitely not proof that your follow-up logic handled a bad delivery outcome correctly.

That gap creates a bunch of quiet bugs:

your UI says "message sent" too early
your retry job never runs because the app thinks the work is already done
your webhook or polling code handles delivered but not undelivered
support ends up debugging customer complaints that started as an async status transition, not a failed API request

What I would test before production

If I only had time for one narrow Twilio test, I would test the branch where the message gets accepted first and fails later.

That means checking:

your app stores the SID from the first response
you can fetch the message again and read the later status instead of assuming the first response told the whole story
your callback or polling path updates the final state correctly
the rest of your system reacts differently to delivered vs undelivered

This is the same reason SMS flows feel harder than they look in Postman. Postman proves the request shape. It does not prove the delivery story.

Why this is a better local test than another happy path

A happy path SMS demo is easy to trust too early.

You send one message, get one SID, see one success response, and tell yourself the integration is basically done.

But the production pain usually sits in the branch after that:

carrier rejection
invalid destination
quiet delivery failure
app state that never gets corrected after the async update

That is why I like narrow workflow tests more than broad "Twilio integration" tests. A small delivery-failure workflow tells you more than a generic sandbox smoke test ever will.

If you want to make this easier locally

I wrote a runnable Twilio docs portal on FetchSandbox because I kept wanting the same thing: send the message, fetch it again, and inspect the later state without jumping between too many tools.

The useful part is not just mocking the first response. It is being able to test the full "accepted first, failed later" branch before production traffic teaches it to you.

Curious how other people handle this one. Do you mostly poll message state, rely on callbacks, or just treat the first 201 as "good enough" until support says otherwise?

Why Paddle's subscription.activated arrives before subscription.created

FetchSandbox — Thu, 30 Apr 2026 23:57:15 +0000

You'd think events fire in the order things happen. They don't.

I was building a Paddle integration last week. Subscription billing, nothing fancy. Customer clicks buy, Paddle handles checkout, my app gets webhooks and updates the database.

The flow should be simple:

Customer completes checkout
subscription.created fires
subscription.activated fires
My app inserts a row on .created, updates status on .activated

That's what I built. It worked great in my head.

What actually happened

In production, subscription.activated arrived before subscription.created about 30% of the time.

My handler did a database insert on subscription.created:

case 'subscription.created':
  await db.insert(subscriptions).values({
    paddleId: event.data.id,
    status: 'created',
    customerId: event.data.customer_id,
  });
  break;

And an update on subscription.activated:

case 'subscription.activated':
  await db.update(subscriptions)
    .set({ status: 'active' })
    .where(eq(subscriptions.paddleId, event.data.id));
  break;

When .activated arrived first, the update found zero rows. No error, no exception. The WHERE clause just matched nothing. The update silently did nothing.

Then .created arrived and inserted the row with status created. But the .activated event was already gone. So the subscription was stuck in created status forever.

Customers had paid. Paddle showed them as active. My app showed them as pending. Support tickets started coming in.

Why this happens

Paddle does not guarantee webhook delivery order. Their docs mention it briefly but it's easy to miss when you're focused on the API endpoints.

The events are fired from different internal services. subscription.created comes from the subscription service. subscription.activated comes from the billing service after payment confirmation. They are async. They race.

This is not unique to Paddle either. Stripe has the same problem with payment_intent.created vs charge.succeeded. Most payment providers have some version of this.

The fix

The handler needs to be idempotent and order-independent. Every event should be able to create or update:

case 'subscription.created':
case 'subscription.activated':
  const status = event.event_type === 'subscription.activated' 
    ? 'active' : 'created';

  await db.insert(subscriptions)
    .values({
      paddleId: event.data.id,
      status,
      customerId: event.data.customer_id,
    })
    .onConflictDoUpdate({
      target: subscriptions.paddleId,
      set: { 
        status: sql`CASE WHEN ${status} = 'active' THEN 'active' ELSE ${subscriptions.status} END`
      },
    });
  break;

The key parts:

Both events can create the row if it doesn't exist
On conflict, active always wins over created regardless of arrival order
No silent failures, no missing updates

Testing this is the real problem

The ordering bug is easy to fix once you know about it. The hard part is reproducing it during development.

You can't control the order Paddle sends webhooks. You can't make .activated arrive first on demand. In testing you might run through the flow 20 times and the events always arrive in order. Then in production with real network latency and load, they don't.

I ended up testing this by sending the webhook events manually in the wrong order against a local sandbox. activated first, then created. Immediately saw the bug. Fixed it in 10 minutes.

The debugging in production took 4 hours.

If you're integrating Paddle or any payment provider with webhooks, test with events arriving in every possible order. Not just the happy path order from the docs.

Test Paddle webhook ordering in a sandbox →

The takeaway

Webhook events are not a queue. They are concurrent messages from different services that happen to be about the same thing. Your handler has to treat every event as potentially the first one it sees for that resource.

If your handler has an insert for one event type and an update for another, you have this bug. You just haven't hit it in production yet.

DEV Community: FetchSandbox

Brownfield Slack alerts: a 6-minute guided MCP run on Stripe + Resend webhooks

The ask (and why it is not a greenfield task)

What “guided” means in practice

Step 1 — Introspect

Step 2 — Comprehend (the load-bearing step)

Step 3 — guide() routing

Step 4 — Discovery (failures tab matters)

Step 5 — Proof run (and the honest limit)

What the agent got right without me asking

What was not done in this recording

MCP setup (unchanged from shorter demos)

The takeaway

Test Resend webhook reconciliation before production

The small bug that becomes annoying later

Testing only the send call is not enough

Why this is awkward to test early

The workflow I wanted from my IDE

What made the validation useful

Try the workflow

Run APIs before setup

The first thing I want is the workflow

What I am building

Testing Resend is not just POST /emails

The first request is not the workflow

Running the Resend workflow from Claude or Cursor

Why this helped me

Try it

Runnable API integration workflows from your favorite IDE

What you configure

What you can ask your IDE

Why this is different from a mock server

Where FetchSandbox fits

Test Cal.com booking flows without calendar chaos

The specific workflow

The bug shape

What I would assert

Why static mocks miss it

Where FetchSandbox fits

Test Notion database queries without a workspace

The specific workflow

Why docs and mocks miss this

How I would test it

1. Happy path

2. Permission denied

3. Empty result

Where FetchSandbox fits

When your SaaS API has docs but no real sandbox

The problem is not the first 200

The workflow small SaaS teams should expose

Why examples are not enough

The failure mode

Why small SaaS APIs skip sandboxes

A better minimum sandbox

How I am thinking about this in FetchSandbox

Polar external_id reconciliation: the customer field that keeps checkout tied to your user

The bug is not dramatic

The small workflow I want to test

Why this catches real billing bugs

Why a static mock is not enough

Testing it in FetchSandbox

Test Polar's customer and product API flow without an API token

The boring part is the important part

The first workflow to prove

Why mocks are weak here

Testing Polar in FetchSandbox

What this catches early

Where the real Polar sandbox still matters

How to test Twilio message delivery failures locally

The narrow workflow that matters

Where teams usually fool themselves

What I would test before production

Why this is a better local test than another happy path

If you want to make this easier locally

Why Paddle's subscription.activated arrives before subscription.created

What actually happened

Why this happens

The fix

Testing this is the real problem

The takeaway

Step 3 — `guide()` routing