The Problem Request Replay Solves
Every developer who handles webhooks or API callbacks has hit this wall. Your backend had a bug, you fixed it, and now you need to test it — but you cannot easily make Stripe, GitHub, or your partner API fire the exact same event again.
Without Request Replay
- ✗Manually trigger a new payment in Stripe test mode
- ✗Push a commit to GitHub to re-fire a push event
- ✗Ask a teammate to repeat the exact action that caused the bug
- ✗Wait for the next scheduled webhook from a third-party provider
- ✗Write a throwaway script to fake a similar payload
With MockFlow Replay
- ✓Capture the original request once
- ✓Fix your backend code
- ✓Click Replay — MockFlow re-sends the exact request
- ✓See the response immediately
- ✓Modify the payload and replay again if needed
How MockFlow Request Replay Works
Capture the Request
Your webhook provider or API caller hits your MockFlow Request Catcher URL. MockFlow stores the full request — method, headers, body, query params.
Open the Replay Dialog
Select the captured request in the inspector. Click Replay. Enter the target URL, optionally modify headers or body, and confirm.
See the Result
MockFlow forwards the request and shows you the response: status code, response time, and body. Every replay attempt is stored in history.
What Gets Replayed
When you replay a request, MockFlow sends the following to your target server — preserving the original request exactly.
# Original captured request (from Stripe):
POST https://api.mockflow.io/my-project--abc/catch/xyz
Stripe-Signature: t=1234567890,v1=abc123...
Content-Type: application/json
{
"id": "evt_1Nxyz",
"type": "payment_intent.succeeded",
"data": { "object": { "amount": 4999, "currency": "usd" } }
}
# ---
# MockFlow Replay → target: https://your-app.com/webhooks/stripe
POST https://your-app.com/webhooks/stripe
Stripe-Signature: t=1234567890,v1=abc123...
Content-Type: application/json
{ same body as above }
# Replay response:
# HTTP 200 | 12ms
# {"received": true}When to Use Request Replay
After Fixing a Bug in Your Webhook Handler
You identified the problem, shipped the fix, and now need to verify it. Replay the exact request that caused the failure instead of waiting for the provider to fire it again.
Testing Against a New Environment
Your staging server is ready but it has never received a real payload. Replay the production-style captured request to warm up the new environment.
Debugging With a Colleague
Share the target URL with a colleague who is debugging the same request. They replay the same captured payload against their own test server.
Validating Different Response Behaviors
Replay the same event with a modified body or different headers to verify edge case handling — missing fields, unexpected values, malformed tokens.
Rate-Limited Providers
Some providers rate-limit webhook test events or require manual triggers. Replay from MockFlow bypasses that entirely after you capture one real event.
HTTP Request Replay FAQ
What is HTTP request replay?
HTTP request replay is the ability to take a previously captured HTTP request — its method, headers, body, and path — and re-send it to any target URL. This is useful when you want to test your webhook handler, debug an integration, or reproduce a specific request without waiting for the original source to fire it again.
How does MockFlow request replay work?
When MockFlow captures a request on a Request Catcher URL, you can open that request and click Replay. A dialog lets you specify a target URL (including localhost), override the method, and modify headers or the body. MockFlow sends the request from its servers to your target and shows you the response status, time, and body.
Can I replay a webhook to localhost?
Yes, if your local server is reachable from the internet — for example via ngrok, Cloudflare Tunnel, or a public IP. MockFlow sends the replay request from its servers, so your target needs to be publicly accessible. If you need to replay to a strictly private local server, copy the request as cURL and run it from your own machine.
Can I modify the request before replaying?
Yes. The replay dialog lets you change the target URL, override the HTTP method, edit the request headers as JSON, and modify the body text. This is useful for testing how your handler handles slightly different payloads.
Is request replay replay history saved?
Yes. Every replay attempt is stored as a ReplayRecord on the original captured request. You can see the target URL, response status, response time, and any error message for each replay.
Can I disable replay for a project?
Yes. In your project settings you can toggle catcherReplayEnabled off. This disables the replay feature for all catchers in that project.