Capture, inspect, and replay webhook requests

Point a provider at your Yellorn capture URL, see exactly what it sent, then replay that request to your own handler — or relay it to another service — straight from the request log.

When a webhook misbehaves, the hard part is usually reproducing it. The provider fired once, your handler threw, and now you're staring at a stack trace with no way to make the same request happen again. Yellorn closes that loop: capture the real request at a live URL, inspect exactly what arrived, then replay it against your own handler as many times as you need — all in the browser, no CLI and nothing to install.

Publish any payload as a mock endpoint (see What is a mock API webhook) and you get a public HTTPS URL on Cloudflare's edge. Point the provider — Stripe, GitHub, Shopify, or your own service — at that URL, or copy it as a curl command to fire a test by hand. Every hit is recorded in an owner-only log.

Webhook portal header showing a live https://yellorn.com/api/webhook/ endpoint URL with Copy URL, Copy as cURL, and Send request buttons, plus a 200 response status selector
Your capture endpoint: copy the URL into a provider's dashboard, or grab it as a cURL command to send a test request yourself.

Open a request in the log and every detail is there: the HTTP method, the URL query parameters, the full request headers, and the raw body. The body viewer has Raw, Whitespace, and Hex modes, so an invisible-character bug — a stray \r, the wrong line ending, a mangled multipart boundary — is obvious instead of hidden (see Fix multipart/form-data 400 errors). This is the ground truth of what your client actually sent, not what you assume it sent.

Recent Requests log with four captured requests; the top POST is expanded to the Req Body tab showing a Stripe payment_intent.succeeded JSON payload, with Send, Copy as cURL, Copy as JSON, and Open in editor action buttons
Expand a captured request to read its params, headers, and body. The action row on the right lets you Send (replay) it, copy it as cURL or JSON, or open it in the editor.

Click the Send action in the request's toolbar and a composer opens, already filled in with the captured method, headers, and body. Type a destination URL — a local tunnel, a staging server, or another service entirely — and click Send. Yellorn dispatches the request and shows you the response inline: status code, latency, response size, and the body in the same Raw / Whitespace / Hex viewer.

"Include captured headers" is on by default, so a provider's signature header and the original User-Agent ride along unchanged — the destination sees the request as if the provider sent it. Framing headers (host, content-length) and Yellorn's loop-guard header are stripped automatically so the replayed request is always valid.

The Send composer with a destination URL, POST method, 'Include captured headers' checked, the captured Stripe body pre-filled, and a green 200 OK result in 278 ms echoing back the forwarded stripe-signature and user-agent headers
The captured request, replayed to a real endpoint: 200 OK in 278 ms, with the response confirming the forwarded signature and user-agent headers arrived intact.

The request is dispatched from Cloudflare's edge, which can't reach localhost or a private IP on your network. To replay against a server on your own machine, expose it with a tunnel — ngrok, Cloudflare Tunnel, or similar — and point the destination at the public tunnel URL. The request then arrives at your local handler byte-for-byte as the original did, so you can step through it in a debugger.

The composer is fully editable before you send. Change the method, toggle the captured headers off to test without a signature, or edit the body to reproduce an edge case or fix a malformed field. Each Send is a fresh request, so you can iterate: tweak, send, read the response, tweak again — no waiting for the upstream provider to fire another event.

Need the request somewhere else? The same toolbar copies it as a ready-to-run cURL command or a JSON object, or opens it in the editor, where you can convert, repair, or diff it against another payload.

Yellorn deliberately does not forward every incoming webhook automatically. Auto-forwarding would put an unreliable second hop on your capture endpoint's critical path, invite retry storms, and hand abusers a relay. A manual, explicit replay is the opposite: it happens only when you click Send, against a URL you chose, exactly once. That keeps the capture endpoint fast and predictable while giving you a precise debugging tool — the request you want, resent when you want it.

How do I replay a webhook request?

In Yellorn's webhook portal, open the request log, expand the request you want, and click the Send action in its detail toolbar. The captured method, headers, and body are pre-filled into a small composer — set a destination URL and click Send to replay the exact request against your own handler or any public endpoint.

Can I resend a captured webhook to localhost?

Not directly: requests are dispatched from Cloudflare's edge, which can't reach your machine. Expose your local server with a tunnel such as ngrok or Cloudflare Tunnel, then point the Send destination at the public tunnel URL. The replayed request then reaches your local handler exactly as the original webhook did.

Does the replay keep the original request's headers?

Yes. 'Include captured headers' is on by default, so headers like a provider's signature and the original user-agent are forwarded unchanged. Framing headers that must match the new request (host, content-length) and Yellorn's internal loop-guard header are always stripped, so the destination receives a clean, valid request.

Can I edit the request before resending it?

Yes. Before sending you can change the HTTP method, switch the captured headers off, and edit the body in place. That makes it easy to reproduce an edge case, retry with a corrected payload, or probe how your handler responds to a single tweaked field — without waiting for the provider to fire again.

Is replaying a webhook safe and private?

Every replay is a single request you trigger explicitly — there is no automatic forwarding and nothing is retried behind your back. The destination must be a public URL (private and internal addresses are blocked), and the captured data goes only to the address you type. See the Privacy Policy for how request logs are stored.

Try a fix in the editor or browse more articles.