# Webhook tester

> Get a URL that catches webhooks, and read every field that arrives.

The webhook tester gives you a unique URL that receives real webhooks, shows each request the moment it arrives, and lets you read its body, headers and query parameters — plus a handler in your language that verifies the signature correctly.

Also: webhook tester, webhook test url, receive webhooks, capture webhook payload, inspect webhook request, webhook debugger, test webhook endpoint online, webhook request bin, see what a webhook sends.

## What it does

When a webhook is not working, the first question is always what actually arrived — and that is the one thing your own server usually cannot tell you, because the request either never reached it or was consumed before anything logged it. Point the provider at this URL instead and every request is captured in full: the JSON body, the headers the provider really sent, the query string, and the raw request as it came off the wire. The transport headers our own edge adds are separated out, so what you are reading is the caller's request and not proxy noise. You can also fire a realistic Stripe, GitHub, Shopify, Slack or Twilio event at the URL yourself, so the page works before you have configured anything upstream.

## When to use it

- A provider says it is delivering webhooks and you want to see what it is actually sending.
- You need a provider's exact payload shape before you write the handler for it.
- Your signature verification is failing and you want to see the signature header as sent.
- You are configuring a webhook in a dashboard that demands a reachable URL before it will save.
- You want to know which headers a provider sends, rather than what its docs claim it sends.
- You need to confirm a provider is retrying, and how often.

## What you give it

| Input | Meaning |
| --- | --- |
| One click | Press Create a webhook URL and you have one. There is no form to fill in, no sign-up and no configuration step. |
| Your provider's webhook setting | Paste the URL into whatever is going to call it — a provider dashboard, your own code, or a curl command — and trigger an event. |
| A sample event (optional) | Stripe, GitHub, Shopify, Slack or Twilio. Each fires a realistic body with the header set that provider actually sends, at your own URL, so you can see the tool work immediately. |

## What you get back

| Output | Meaning |
| --- | --- |
| A live capture log | Every request that arrives, newest first, with its method, path, status and how long ago it landed. The service keeps the last 100 per URL. |
| The full request | Body (pretty-printed when it is JSON), the headers the caller sent, query parameters, and the raw HTTP request. Copyable as JSON or as a runnable curl command. |
| Handler code | A starter handler in Node.js, Python, Go, Ruby, PHP or Java that reads the raw body, verifies the signature in constant time using the header your caller actually sent, and only then parses. Fully visible and copyable. |

## Key terms

- **Webhook** — an HTTP request a service sends you when something happens, rather than one you send asking. What receives it is an ordinary endpoint that accepts a POST.
- **Signature verification** — a header carrying an HMAC of the request body, computed with a secret only you and the provider know. It is what proves the request came from that provider rather than from anyone who learned your URL.
- **Raw body** — the exact bytes the caller sent. Signatures are computed over these, so any middleware that parses and re-serialises the body before your verifier runs will invalidate a signature that was perfectly valid on arrival — the single most common cause of a failing webhook check.
- **Replay window** — the age at which a provider stops accepting a signed request even if the signature itself is valid. Stripe rejects anything with a timestamp more than five minutes old, so a clock skew on your server reads as a signature failure.

## Questions

### Do I need an account?

No. Press Create a webhook URL and it starts receiving immediately. Signing up is only needed to keep the URL and the requests it captured.

### How long does my URL stay live?

As long as this tab's session lasts, which is a matter of minutes rather than days — it is a throwaway URL for looking at a payload, not a permanent endpoint. There is no way to extend it: the URL belongs to the anonymous session that created it, so when that session ends the tool tells you and offers a new URL. Sign up free to get one that is permanent and tied to your workspace.

### Is my webhook URL private?

It is unique and unlisted, but it is not a secret in any strong sense — anyone who has the URL can send requests to it, and anything sent to it is visible in this tab. Treat it like a shared link: fine for test events, not somewhere to point production traffic carrying real customer data.

### My provider's signature verification fails on these requests. What is wrong?

Almost always body-parsing middleware running before your verifier. The signature covers the exact bytes that arrived, so anything that parses and re-serialises the body first — express.json(), request.json, a framework default — changes those bytes and breaks a signature that was valid. Read the raw body, verify it, then parse; the handler code on this page does exactly that. The other usual causes are mixing test-mode and live-mode secrets, reading the wrong header (GitHub sends X-Hub-Signature-256, not X-Hub-Signature), and a server clock skewed further than the provider's timestamp tolerance.

### Why are there headers I did not send?

Your request passes through a CDN and a service mesh on the way in, and both add their own headers. Those are listed separately from the caller's, so the Headers tab shows what the provider sent rather than two dozen routing and tracing headers. The curl command this page generates replays only the caller's headers, for the same reason.

### Can I make it return a specific status code or body?

Not in this tool. Every request gets a 200 with a small JSON acknowledgement, which is what a provider needs to consider delivery successful and stop retrying. Custom and conditional responses are part of webhook listeners in the Postman app.

### Can I replay a captured request to my own server?

Not from here. Sign in with a free Postman account to replay any captured request to any URL, including a local server over a tunnel such as ngrok or cloudflared.

### How many requests does it keep?

The last 100 per URL, newest first. The list shows the most recent 20 at a time.


## Privacy

Anything sent to your URL is stored by the webhook listener service for the life of the listener so that it can be displayed here, and is readable by the anonymous session that created the URL — which means this browser tab. Because the URL is unlisted but not authenticated, do not point production traffic carrying real customer data at it. The sample events are sent by Postman's Cloud Agent rather than from your browser, so that the provider headers that make them realistic survive; no signing secret is involved, and this tool never asks for one.

## Links

- [Use the tool](https://www.postman.com/tools/webhook-tester) — the interactive version of this page.
- [Postman Tools](https://www.postman.com/tools) — every free tool in this set.
- [Webhook docs](https://learning.postman.com/docs/use/send-requests/protocols/webhooks/) — Postman documentation.