Webhook Inspector

A webhook inspector is a tool that captures inbound HTTP requests and shows you exactly what arrived: the method and path, every header, the raw body, and when it landed. You get a URL, you paste it wherever a vendor asks for a webhook endpoint, and you watch the requests come in. The tools people mean by this are webhook.site (opens in a new tab), mockbin.io (opens in a new tab), PostBin (opens in a new tab), and RequestBin — often called "request bins" or "webhook testers" instead.

They exist because a webhook is otherwise invisible. The vendor's dashboard says "delivered"; your server says "400"; nobody can see the bytes in between. An inspector makes those bytes visible with no code and no deploy.

For that job, a disposable bin is the right tool, and it is faster than Slashbin. We're not going to pretend otherwise on a page about the category. Below is what an inspector is genuinely good at, how the common ones differ, and the point at which the job stops being inspection.

What a disposable request bin is better at

• Zero signup, zero configuration, zero cost. Open the page, get a URL, paste it into the vendor's dashboard. mockbin.io states it plainly — "Mockbin is free of sign-ups. Bin IDs are only stored in your browser storage." Slashbin requires an account and a card for its 14-day trial. For a ten-second question, that's the wrong trade, and you should use the bin.
• Answering "is the vendor sending anything at all?" in under a minute. This is the single most common webhook question, and an inspector answers it faster than any gateway, ours included.
• A disposable URL you can paste into a ticket. Share it with the vendor's support team, watch the delivery together, throw it away. There's nothing to migrate and nothing to turn off afterwards.
• Jobs a gateway doesn't do at all. mockbin.io will mock an API response — a fixed status, headers, and body, or a whole set generated from an OpenAPI 3.1 document — so you can build against an endpoint that doesn't exist yet. PostBin ships an API for draining a bin from CI so a test can assert on what your code sent. Slashbin does neither; it receives real vendor traffic rather than standing in for a vendor.
• Local development against a live sender. webhook.site's whcli forward streams captured requests to localhost, which is a better dev loop than routing production-shaped traffic through a gateway.

Where inspection ends

Inspection is a step, not a system. It is the thing you do on day one of an integration, and the failure mode is that the integration outlives the bin.

The requests you looked at are gone — PostBin bins expire after 30 minutes by design, webhook.site's free URLs cap out on both request count and age, and mockbin.io keeps your list of bins in browser local storage, so it disappears when you switch machines. None of that is a defect. A scratchpad is supposed to be disposable.

But the questions change once the vendor is sending real events:

• The transform broke on an event from last Tuesday. Where is that payload?
• The destination was down for twenty minutes. Who retried, and did every event eventually land?
• The same event needs to reach three services now. Who fans it out?
• Finance is asking whether a specific order actually made it through three weeks ago. What's the evidence?

An inspector answers none of these, because it was never trying to. That's the boundary this category has: a bin is where you look at a request once; a gateway is where a request lives on its way to production destinations. Slashbin is the second thing.

Concretely, that means the payload is stored byte-for-byte, transformed and validated against a Golden Model so downstream code reads one shape no matter which vendor sent it, fanned out to every destination that needs it with per-destination retries and circuit breaking, and replayable through the current pipeline when you ship a fix — without asking the vendor to re-send. Every attempt is logged with its response code, body, and timing.

The usual sequence is both, in order: a bin during vendor onboarding, a gateway once the integration is real.

Feature comparison

This table compares the category — a disposable request bin — against a gateway. Individual inspectors differ; the per-tool pages linked below have the specifics.

Verified on 2026-07-30 against the live webhook.site (opens in a new tab), mockbin.io (opens in a new tab), and postb.in (opens in a new tab) sites and their public documentation. webhook.site renders its free-tier request cap and URL expiry dynamically rather than publishing fixed numbers on the landing page, so those are marked as capped rather than given a figure. Slashbin rows verified against the live product and pricing page the same day.

"Not the product model" means the tool isn't trying to do that job. It runs in both directions on this table: a bin is a capture surface and not a delivery gateway, and Slashbin genuinely cannot mock an API or act as a test assertion target.

Which inspector to use

• webhook.site — the most feature-complete of them, and the one with a CLI tunnel to localhost. Start here if you're picking an inspector today with no other constraint.
• mockbin.io — free, MIT-licensed, self-hostable, and it mocks responses as well as capturing them. Also the answer if you arrived here because mockbin.org stopped resolving.
• PostBin — 30-minute bins and an API built for asserting on outbound requests from CI.

Related reading

• All comparisons — every tool Slashbin is compared against, including the delivery gateways that sit outside the inspector category.
• Webhook Debugging — the four places a webhook dies, and what evidence tells them apart once inspection isn't enough.
• Webhook ETL — the category Slashbin fits in, and why point-to-point handlers stop scaling.
• Replay — re-drive a stored event through the current transform + delivery pipeline.
• Fan-out — deliver one inbound event to N destinations, each with its own filter and retry policy.