About

Founder of FetchSandbox. Ex Meta, PayPal, Pinterest, and IBM. After spending 15+ years building APIs and developer platforms at Meta, PayPal, Pinterest, and IBM, I kept seeing the same problem: integration tests stop at 200 OK, but production failures happen in webhooks, retries, state transitions, and async workflows. I'm building FetchSandbox to help developers and AI agents verify real integration behavior before shipping. Today it powers runnable environments for APIs like Stripe, Clerk, Resend, Twilio, and more through MCP, CLI, and the web. Always happy to chat with founders, developer tooling teams, API companies, and engineers building for the agent era.

Badges

Buddy System
Buddy System
Pixel perfection 💎
Pixel perfection 💎
Plugged in 🔌
Plugged in 🔌
Thought Leader
Thought Leader
View all badges

Maker History

Forums

FetchSandbox managed tunnel: a reachable local endpoint is not the same as verified behavior

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.

Stripe customer sweeps: refusing writes when the scan comes back short

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.

verifying approval-wait boundaries in cancellation workflows

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.

View more