FlurryPORT

Thanks Zain! the regression angle is exactly the intent: auto-replay per endpoint plus saved collections turn real production traffic into a repeatable suite you re-run on demand, no hand-written fixtures. On signatures I'll keep it short since I went deep on it in the thread with Thomas: raw bytes stored and replayed verbatim, signature headers and querystring forwarded untouched, so it passes your real verify step and lets you drive the failure paths. And yes. Replay is a first-class MCP tool call today. replay_to_target replays a captured event server-side to a registered destination, forward_to_localhost sends captures straight to your local handler (start_echo_server spins up an instant one), plus list_replay_targets / list_replay_executions / get_replay_execution to drive and inspect runs — npx -y flurryport mcp and point your editor at it. (The coming-soon piece I mentioned above is the AI-assisted transformation/recipe layer, not replay itself.)

Auto-replay per endpoint plus saved collections basically turns captured production traffic into a regression suite, which is a nice side effect of a debugging tool.

Byte-for-byte replay that keeps the original signature valid is the part that matters, since hand-rolled test payloads always fail verification. Does the MCP server expose replay as a tool call?

Yes — and to your exact concern: the raw body is stored and replayed byte-for-byte, never re-serialized. We read the raw bytes on capture, encrypt them at rest, and send those exact bytes back on replay (as a byte array, no JSON round-trip), so an HMAC over the payload still matches. We actually keep a diagnostic that recomputes the Stripe HMAC-SHA256 off a stored capture and checks it against the original Stripe-Signature header — that's how we confirm the round-trip stays bit-exact. Signature headers and the querystring forward verbatim. The only headers we don't copy are hop-by-hop (Content-Length, Connection, Transfer-Encoding), which the transport regenerates and which aren't part of any signature. So you can replay straight through your real verify step and exercise the failure paths. Replay fires manually or automatically as requests land (auto-replay per endpoint), and you can inspect every request and save collections to re-run to your heart's content. Coming soon (not live yet): an MCP/recipe layer where your AI helps build transformations and debug against your captures — best-effort PII redaction on what it sees, and your delivery credentials never reach it at all (it works with secret names, never values). Everything else above is shipping today.

The replay angle is the useful bit — most webhook debugging dies because you can't re-fire the exact original request. Before I'd wire this in front of my handlers: do you preserve the raw body bytes and the original signature headers verbatim? For HMAC-signed webhooks (Stripe, GitHub, etc.) a replay is only useful if it still passes signature verification, and any re-serialization of the JSON body breaks the hash. If the raw payload survives byte-for-byte and I can replay through my real verify step, that's genuinely valuable for testing the failure paths.