What is a webhook tester and when do I need one?

A webhook is an HTTP request that one service sends to your server when something happens — a payment clears, a pull request opens, an SMS arrives. Debugging one is awkward because you cannot see what the sender actually sent until you have a working receiver. A webhook tester gives you a public URL that accepts anything, records it, and shows it back to you. It is the fastest way to answer 'is the provider even calling me, and what does the payload look like?' before you write a single line of handler code.

How long do captured requests stay available?

A capture URL stays alive for two hours after the last request or page refresh, and up to 24 hours in total. Each bin keeps the 30 most recent requests; older ones drop off as new ones arrive. Bodies larger than 8 KB are stored truncated, and requests over 256 KB are rejected outright — enough for real payloads, not enough to be abused as storage.

Which HTTP methods does the capture URL accept?

GET, POST, PUT, PATCH, and DELETE. Every one returns HTTP 200 with a small JSON acknowledgement, which keeps providers that retry on non-2xx responses happy. Query strings, custom headers, and any content type all get recorded.

Can I see the raw body, or only formatted output?

Both, in effect. JSON is pretty-printed with two-space indentation, form-urlencoded bodies are decoded into key/value lines, and XML is indented. If a body claims to be JSON but does not parse, the tool says so and shows the bytes exactly as they arrived — which is usually the bug you were hunting.

Is this a free webhook.site alternative?

It covers the same core job — a disposable URL that captures and displays requests — without an account, an upgrade prompt, or a request quota. What it does not do is the paid-tier extras: custom responses, XHR redirect, WebSocket endpoints, or permanent URLs. If you need scripted responses, webhook.site or RequestBin are better fits. For 'show me what this provider is sending', this is faster.

Can I test webhooks from localhost with this?

You can test what a provider sends, but not forward it to your machine — that needs a tunnel like ngrok or cloudflared. The common workflow is to use both: capture here first to learn the exact payload shape and headers, build your handler against that, then switch the provider to a tunnel URL once the handler is written.

Why is my provider's webhook not showing up?

Check three things in order. First, that the URL was copied whole — a truncated bin id gives a 404 that most dashboards report as a generic failure. Second, whether your provider requires a verified or HTTPS-only endpoint; the capture URL is HTTPS, so that is usually fine. Third, look at your provider's own delivery log — Stripe, GitHub, and Shopify all show the response they received, and a 404 there means the bin expired and you need a fresh URL.

Is it safe to send real webhook payloads here?

No, and it is worth being blunt about it. Anyone with your URL can read what lands there, exactly as with every public request bin. Use test-mode credentials and sample events. If you need to inspect a live payload containing customer data, capture it on infrastructure you control instead.

Webhook Tester — Free Online URL to Capture HTTP Requests

Your capture URL

Try it from the terminal

You get a throwaway URL the moment this page loads. Point any webhook at it — Stripe, GitHub, Shopify, Zapier, your own cron job — and every request that lands shows up below within a few seconds, with the method, headers, query string, and body laid out and pretty-printed. Nothing to install, no account, no email.

How it works

1
Copy your capture URL A unique URL is generated as soon as the page loads. Click Copy URL, or select the field and copy it manually. The URL keeps working after you close the tab, and the same one comes back when you return.
2
Point a webhook at it Paste the URL into your provider's webhook settings — Stripe, GitHub, Twilio, Shopify, n8n, Make — or fire a request yourself with the curl command shown under the URL.
3
Read the request Captured requests appear newest first and refresh every three seconds. Expand any one to see all headers, query parameters, and the body with JSON, form data, and XML formatted for reading.

Where captured requests live

Requests sent to your capture URL are held in memory on the belun.app API server so the page can show them back to you — that is the whole point of a webhook receiver, and it cannot be done in the browser alone. Nothing is written to disk or to a database. A bin is deleted two hours after its last activity, or when you click Clear. Anyone who knows your URL can send requests to it, so treat the captured data as public: use test-mode keys and dummy payloads, never production secrets or real customer records.

Frequently asked questions

What is a webhook tester and when do I need one?: A webhook is an HTTP request that one service sends to your server when something happens — a payment clears, a pull request opens, an SMS arrives. Debugging one is awkward because you cannot see what the sender actually sent until you have a working receiver. A webhook tester gives you a public URL that accepts anything, records it, and shows it back to you. It is the fastest way to answer 'is the provider even calling me, and what does the payload look like?' before you write a single line of handler code.
How long do captured requests stay available?: A capture URL stays alive for two hours after the last request or page refresh, and up to 24 hours in total. Each bin keeps the 30 most recent requests; older ones drop off as new ones arrive. Bodies larger than 8 KB are stored truncated, and requests over 256 KB are rejected outright — enough for real payloads, not enough to be abused as storage.
Which HTTP methods does the capture URL accept?: GET, POST, PUT, PATCH, and DELETE. Every one returns HTTP 200 with a small JSON acknowledgement, which keeps providers that retry on non-2xx responses happy. Query strings, custom headers, and any content type all get recorded.
Can I see the raw body, or only formatted output?: Both, in effect. JSON is pretty-printed with two-space indentation, form-urlencoded bodies are decoded into key/value lines, and XML is indented. If a body claims to be JSON but does not parse, the tool says so and shows the bytes exactly as they arrived — which is usually the bug you were hunting.
Is this a free webhook.site alternative?: It covers the same core job — a disposable URL that captures and displays requests — without an account, an upgrade prompt, or a request quota. What it does not do is the paid-tier extras: custom responses, XHR redirect, WebSocket endpoints, or permanent URLs. If you need scripted responses, webhook.site or RequestBin are better fits. For 'show me what this provider is sending', this is faster.
Can I test webhooks from localhost with this?: You can test what a provider sends, but not forward it to your machine — that needs a tunnel like ngrok or cloudflared. The common workflow is to use both: capture here first to learn the exact payload shape and headers, build your handler against that, then switch the provider to a tunnel URL once the handler is written.
Why is my provider's webhook not showing up?: Check three things in order. First, that the URL was copied whole — a truncated bin id gives a 404 that most dashboards report as a generic failure. Second, whether your provider requires a verified or HTTPS-only endpoint; the capture URL is HTTPS, so that is usually fine. Third, look at your provider's own delivery log — Stripe, GitHub, and Shopify all show the response they received, and a 404 there means the bin expired and you need a fresh URL.
Is it safe to send real webhook payloads here?: No, and it is worth being blunt about it. Anyone with your URL can read what lands there, exactly as with every public request bin. Use test-mode credentials and sample events. If you need to inspect a live payload containing customer data, capture it on infrastructure you control instead.

From the blog

How to Test Webhooks Without Deploying Anything A practical walkthrough of debugging webhooks with a disposable capture URL — signatures, retries, and the mistakes that cost the most time. Read the post →