Oct 27 run on app-declared revision c2ec0d5.

The flow scans Stripe customers, flags missing country fields and duplicate emails, caps writes per run, then posts a summary to Asana and Slack twins. Four measured outcomes on this run:

Full scan completed across 250 records and flags were written. Incomplete scan, meaning fewer records returned than expected, produced no writes and triggered a RevOps alert. Write cap paused for approval rather than writing through. Rerun after an initial flagging pass added zero new flags.

Before rerun we fixed our own Stripe twin, which was stopping early, and corrected fixture retries and data isolation. Business expectations stayed unchanged.

Building FetchSandbox, one distinction worth naming: a tunnel can connect successfully before any app behavior has been checked.

The managed tunnel polls a cloud relay and forwards to your configured localhost port. Connection setup reports proof_status: not_tested. That reflects the design: connectivity alone produces no receipt. Forwarded requests and responses also travel through that relay, so teams handling sensitive data should factor that in.

Behavior verification is a separate run: configure the expected app behavior under a specific operation, run it, and collect the receipt. Keeping setup results and application test results separate lets engineers inspect each piece of evidence independently.

This post is based on a November 1-2 inspection of the published fetchsandbox-mcp 0.7.30 package, not a new app verification run.

We ran a Lovable checkout app through FetchSandbox. Six checks passed. Two stayed not checked.

We delayed an email response, but the webhook still returned success. We hadn't shown it recovering after a failed callback. So the overall run stayed incomplete.

That's the thing I want us to get right as we build this. Did the test cause the failure, or did the app just succeed? Same question for a background job that might crash halfway through.

What evidence do you ask for before trusting a recovery test?

When a customer hits cancel, most workflows park at an approval step. The question nobody asks: has anything already been cancelled by then?

We ran a rehearsal on our synthetic Acme demo, wiring FetchSandbox (fetchsandbox.com/mcp) across Stripe, Zendesk, Square, and Slack twins. Three boundaries we actually checked: nothing fires while parked at approval, rejected approval leaves the subscription unchanged, and the workflow survives an app restart while parked then cancels exactly once after approval. 27/27 passed on October 18.

Scope caveat: synthetic provider twins, not live traffic. But that's the point, catching a premature cancellation in rehearsal is cheaper than finding it after a real customer emails you.

AI-assisted code moves fast enough that these intermediate states are genuinely easy to miss. You end up testing the happy path and calling it done.

launch yesterday (july 12th) we told you all about @FetchSandbox.

today i'd rather hear about you.

Since our last launch we've been heads-down on one thing: making "this integration works" actually mean something. Here's what changed, and why we're more confident than a month ago.

What we shipped?

Five integrations now recognize the bugs people actually hit and prove the fix with a real before/after:

What happened

A few weeks ago my coding agent wrote a Stripe webhook handler. Signature check, event type check, fulfillment, clean 200. I approved it in 90 seconds because every line was correct.

And it was, until Stripe delivered the same event twice. Which it's allowed to do. Then the handler credited the customer twice.

Why it slipped through

three bugs an ai wrote for me this week. every test green. all three would've paged me in prod:

1. webhook retried charged the customer twice

2. subscription.activated arrived before subscription.created they paid, app said not entitled

3. a stale event flipped a canceled sub back to active free access, forever

none of these show up in a 200. you find them from a customer or you fire the ugly event orders on purpose and find them first.

we now throw every ordering + every duplicate at your handler and hand back the exact sequence that broke it.

Most Lovable apps I've seen ship with integrations that were never actually run end to end.

What's usually happening?

The Stripe webhook is wired, the retry logic is there, but nobody ran a confirm capture webhook fire sequence before going live. Testing is either skipped or scripted in isolation against mocked responses that don't reflect real API behavior.