FetchSandbox Blog

The AgentMail webhook bug that only fires when a message has attachments

An inbox webhook handler that works perfectly in every test — then silently drops real customer emails with PDFs attached. It's planted in our open-source playground. Reproduce it from your IDE.

Green passed. The AI's fix granted zero seats.

An AI agent "fixed" a Stripe webhook that double-granted seats. CI went green. Paying customers got nothing — because the check only asked whether the count stopped growing, not whether it landed on the right number.

API docs are not activation

FetchSandbox product analytics show the gap clearly: developers read docs and open portals, but activation starts when they run a workflow and see proof.

Brownfield API integrations need handler maps before MCP proof runs

Adding Slack on Stripe failures in a repo that already had Clerk and Resend — why brownfield guided runs take longer, and what FetchSandbox can prove upstream.

Clerk webhook replay can duplicate users in your app state

Replayed user.created events can duplicate local user rows unless your handler upserts by Clerk user ID and idempotency-keys side effects.

We planted a Descope privilege-escalation bug. Try to catch it from your IDE.

An open-source playground with a real flaw: an agent access-key exchange that trusts client-requested scopes. Two tasks, 20 minutes, no Descope account, no API keys.

Deterministic Evals for Coding Agents: Prove the Fix

Run the same API failure against old and fixed code. A deterministic exit-code flip decides the verdict and produces a PR-ready proof receipt.

GitHub webhooks can disappear, so reconcile issue state from the API

GitHub issue webhooks are useful signals, but they are not your source of truth. If your automation gates work on issue state, re-fetch the issue before deciding what happened.

How to Build a Lovable App and Verify Integrations with FetchSandbox

Build a Lovable gym or bookstore, connect FetchSandbox MCP with a key from /keys, then inject webhook retries, 429s, and 401s before live keys.

What 47 r/lovable Posts Say Breaks After Launch

I read 47 r/lovable posts about what breaks once a generated app has real users. Three of them describe failure testing, invented from scratch, with no name for it.

Lovable Built a Pet Store. Checkout Hit a Paddle Twin.

Lovable built Pawsome Pantry with Paddle and Resend. No paid plan, so checkout hit FetchSandbox twins via a secret handoff — not live Paddle.

A Lovable Store Checked Out on Stripe and Resend Twins

Point a Lovable store at Stripe and Resend twins. Preview checkout finished with PaymentIntent pi_XYKYTMFJJU0IR06FSTY2G6RJ and a receipt-emailed confirmation.

Stripe Charged Them. The Lovable App Still Said Free.

Stripe Checkout can succeed while a Lovable app still shows the free plan. Read the same row the UI gates on, then compare it to the twin subscription.

Lovable Stripe Webhooks Return 401 After Every Redeploy

Lovable redeploys can turn Supabase JWT verify back on. Stripe then gets 401 before your webhook code runs. Fire a signed event at the function URL to prove it.

Paddle subscription access control should follow the lifecycle, not one webhook

A Paddle subscription can move from trialing to active, paused, resumed, and canceled. If your app gates access from one event, it will eventually grant or revoke access at the wrong time.

Your Paddle Webhook Is Signed. The Seat Count Is Not.

Paddle custom_data can come from browser checkout code. Verify the signature, then grant seats from paid line items, not client metadata.

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

Four ways we tried to let partners test our API — docs, UAT, IP-whitelisted staging, then production. Each one failed worse than the last.

Replit Agent + Paddle + Resend: Dry-Run Twins Before You Publish

Add FetchSandbox as a Replit MCP connector with a Bearer key, boot Paddle and Resend twins, then prove payment_failed and email_bounced before live keys.

Resend's `email.sent` webhook doesn't mean the email was delivered

POST /emails returns 200. The email.sent webhook fires. Your app marks the email delivered. Then a third of your password resets never reach the inbox. Here's why those two events are not the same thing.

RevenueCat Webhooks Out of Order: Keep Entitlements Correct

RevenueCat webhooks can arrive out of order. Deduplicate by event.id, read authoritative entitlement state, and test convergence before production.

Shopify order paid is not fulfilled, and fulfilled is not closed

A common Shopify webhook bug: your app starts fulfillment or marks an order done on order.paid, but paid, fulfilled, and closed are different lifecycle states.

Stripe checkout.session.completed can beat your customer row

checkout.session.completed often arrives before your app has inserted the customer. If fulfillment assumes the row exists, you silently skip entitlement — while Stripe shows paid.

Stripe dispute evidence needs state, not just a submitted POST

A Stripe dispute can be open, need a response, receive evidence, and still not be won. If your app marks the case handled after one POST, support will lose track of the real state.

A Stripe PaymentIntent at `requires_capture` is not paid yet — but most generated code thinks it is

Coding agents and quickstart snippets routinely treat any 2xx from /payment_intents/confirm as 'paid'. Stripe says otherwise: the response status is requires_capture, not succeeded, and a separate capture step has to fire.

Stripe webhook replay: a valid signature is not a fresh event

Your handler verifies v1= and ships. It never checks t=. A replayed event with a valid signature and a stale timestamp fulfils the order twice.

Lovable Payments Look Fine. Production Still Debugs Them.

Lovable and Base44 apps pass Stripe test mode. A retry can still double-charge. Test the second delivery before production is the debugger.

Test the API integrations Cursor wrote before production

Cursor writes the integration in minutes. Wire FetchSandbox MCP into Cursor to run the workflow, catch retry and idempotency bugs, and prove the fix.

Test Descope auth from your IDE before production keys

Use FetchSandbox MCP to run Descope OTP, magic link, session refresh, and access-key workflows from Cursor or Claude Code — and catch JWT verification bugs before real users.

Test Your Lovable Integration With a Custom MCP Connector

Add a FetchSandbox API key from /keys, paste it as the Lovable MCP bearer token, then boot a twin and inject webhook failures.

Test mid-flow token expiry without rotating real API keys

Happy-path mocks never expire a token between step 1 and step 3. Your production client does. Here's how to force a mid-flow 401 on purpose — without burning partner credentials.

Test a mid-workflow 429 without burning partner API quota

Your retry logic for partner rate limits usually runs once — in production, during the traffic spike. Force a 429 between step 2 and step 3 in a sandbox so the backoff path is proven before launch.

Test your OpenAI 429 handling without burning real quota

Your retry logic for OpenAI rate limits has probably never executed. Triggering real 429s means burning paid quota to test error handling — or shipping backoff code that first runs in production, during the traffic spike that matters.

Test PayPal Refunds in Lovable Before Production

A PayPal refund can succeed while your app records a failure. Force the 422 retry path with a service twin before testing with real money.

Test Stripe charge.refunded without a live refund

Checkout grants access. A refund in Stripe does not. If your webhook ignores charge.refunded, customers keep seats after the money comes back. Prove revoke-once without a live charge.

Test Stripe requires_action (3DS) without real cards

Your checkout treats PaymentIntent succeeded as the finish line. 3DS returns requires_action — and most suites never force that branch. Here's how to prove the client handles next_action before production cards do.

Test webhooks locally without ngrok (or any tunnel)

Your tunnel URL rotated again, the provider dashboard has a stale endpoint, and you still haven't tested the retry path. You don't need webhook delivery to your laptop — you need the delivery lifecycle in a sandbox.

What Is a Verification Layer for Coding Agents?

Cursor, Claude Code, and Lovable write the integration. The request still has to hop MCP, hit a twin, fail on old code, pass on new code, and exit 0.

AI Code Is Cheap. Your Pull Request Still Needs Proof.

AI agents generate code fast. Use an independent sandbox, a before-and-after proof receipt, and a CI workflow gate to verify it before merge.

WorkOS directory sync webhooks need reconciliation after Okta group renames

Okta group renames can arrive through WorkOS directory sync as partial webhook events. If feature gates trust the payload, users split by cache state. Re-fetch the group and users before gating.

You can't code-review a webhook retry

My coding agent wrote a Stripe webhook handler that passed review and CI — and it still would have credited a customer twice on the first retried event. Reading code can't catch this class of bug. Running the failure can.

Test AgentMail webhook scope before tenant leaks

A webhook subscribe call returning 200 only proves AgentMail accepted something. Read it back before tenant scope drifts.

Testing Resend Is Not Just POST /emails

Sending an email is easy. The integration pain starts when you need delivery status, webhooks, and app state you can trust.

Testing API Auth Without Real Credentials

Scope denials, expired tokens, and refresh-token rotation that revokes the grant. How to reproduce all three in a sandbox using the auth contract your OpenAPI spec already declares.

Runnable API Integration Workflows from Your Favorite IDE

How FetchSandbox MCP lets Claude, Cursor, Codex, and other IDE agents run guided API workflows instead of only reading API docs.

The Real API Contract Is the Lifecycle, Not the Endpoint

API integrations break after the first request: webhooks, retries, duplicate events, state changes, and lifecycle behavior.

Stateful API Sandbox vs Mock Server: Why Your Mocks Keep Lying

Mock servers and stateful sandboxes solve different problems. Most teams pick the wrong one and find out in production.

Rebuilding API Debugging Around the Timeline

Two Reddit threads described the same pain: debugging API integrations by stitching logs together like detectives. Here's how we rebuilt the debugger around the question engineers actually ask — what happened across the whole flow?

Paddle Sandbox: A Better Alternative for Developer Testing

Paddle's sandbox needs merchant approval, has rate limits, and shares state across your team. Here's how to test the full subscription lifecycle without any of that.

Testing Stripe Webhooks Without Production Keys: 9 Scenarios That Matter

9 webhook scenarios you should test before shipping — payment declined, 3DS, dispute, refund, retry — without burning real card data.

Why API Integrations Break After the First Successful Request

The first 200 OK feels good. It also hides most of the real work — the state change, the webhook, the retry, the second read.

I Spent 3 Years Building Something That Shouldn't Take 3 Years

A founder story about sandbox drift, docs backlogs, and why the OpenAPI spec should have been enough all along.

The OpenAPI Spec Already Has Everything

Why API teams keep manually rebuilding docs, quickstarts, and sandbox logic that is already implicit in the spec.

Why API Sandboxes Drift From Production

The recurring organizational reasons sandboxes, docs, and quickstarts fall out of sync with real product behavior.