What FetchSandbox does and doesn't do — in plain words

Hey all — ahead of our Aug 2 relaunch, I'd rather be useful than hypey. Here's the honest map: what we test, what we don't (yet), what languages it works with, and where we're going.

The failures we test for (the "it passed, then broke in prod" stuff):

• Double-processing — the same webhook arrives twice; do you charge the customer twice?

• Out-of-order / late events — a "canceled" and a stale "active" land in the wrong order; does a canceled account come back to life? (live for Paddle today)

• Sad paths — card declined, payment failed, thing-not-found; does your code handle it, or quietly mark it "done"?

• Rate limits — the API throttles you (429); do you back off, or silently drop data?

• Wrong-shape responses — the API returns a field you didn't expect or renamed; does your code break downstream?

• Auth slips — bad/expired key, or a read-only key doing writes; caught or not?

• Fake / replayed webhooks — unsigned, tampered, or old signed events; rejected?

• Slow + flaky delivery — delays and dropped webhooks.

Every run hands you a receipt: the failure reproduced, then gone after the fix.

What we DON'T do yet (being straight):

• Pinned/frozen scenarios — our fixtures are still mutable on our end, so an update from us can shift your result. No lockfile yet.

• Drift detection — we don't yet warn you when the real API changes shape vs our model.

• Learning from your own past runs — memory is curated per-API patterns, not your team's history.

• Deep coverage everywhere — we import 60+ specs, but the deep failure library is real for Stripe/Paddle + a handful, thin beyond that.

• Auto-applying the fix, or offline/self-hosted — not this tool (yet).

Languages: it's language-agnostic. The sandbox lives at the API layer, so you point any SDK or HTTP client at it — Node, Python, Go, Ruby, Java, whatever — and drive it from your IDE (Cursor, Claude Code, any MCP editor) or the CLI. Our example apps are Python; that's just the demo.

Where we're headed next:

• Frozen version pins (a lockfile for scenarios)

• A CI action that blocks a PR unless the proof actually passed

• Drift detection when the real API moves

• Long game: memory that learns from your team's own failures

Which of those failure types has actually bitten you — and which one did I miss?