Slashbin vs webhook.site

They're not the same tool. webhook.site is the fastest way in the world to see what a webhook looks like — open the page, get a URL, watch requests land. Slashbin is the piece you keep around after the debugging session ends: a gateway that transforms, validates, and delivers those webhooks to the destinations that need them, with retries and replay when something goes wrong.

Most engineers end up using both.

What webhook.site is better at

Instant, zero-signup inspection. Load the page, get a URL, done. No account, no config, no build. For "does this vendor actually POST anything, and what does it look like," nothing is faster.
One-off debugging and sharing. A disposable capture URL you can paste into a vendor's dashboard, watch a delivery, then throw away.
CLI tunnel to localhost. whcli forward --target http://localhost:... streams captured requests to your dev machine — a good story for local integration work.
A permanent URL on the paid tier. webhook.site sells a fixed custom URL and longer retention, so a paid bin can outlive the debugging session.
Custom responses and scripting. You can script what the endpoint returns — status codes, headers, delays — which makes it a usable mock for the system calling you, not only a viewer.

Where webhook.site stops

These are the limits people hit, in the order they usually hit them.

Your requests expire. A free bin holds a bounded window of recent requests. When the vendor fires the event you needed at 3am and you look the next morning, it may already be gone. There is no way to replay something you no longer have.

Nothing is delivered anywhere. webhook.site is a terminus. It receives, it displays, it stops. If the payload has to reach your API, your warehouse, or a third-party system, that is code you write and operate yourself.

No transformation. You see the raw payload — often several hundred fields of it. Reshaping that into what your system actually consumes is a parsing job on your side, and it has to be maintained as the vendor changes their schema.

No retries. If your destination is down when the webhook arrives, the event is lost. There is no queue behind the bin and no backoff.

It is not a production endpoint. No signature verification against the sending vendor, no rate limiting, no per-source access control, no delivery record you can audit later.

If you are still debugging, none of this matters and webhook.site is the faster tool. It matters the moment the integration has to keep running without you watching it.

What Slashbin is better at

Being the permanent piece. Slashbin sits in your production pipeline, receiving the vendor's traffic every day — not just during the first debugging session.
Transform and validate against one schema. Every inbound event is reshaped and checked against a Golden Model. Downstream code reads one canonical shape no matter which vendor sent it.
Deliver to real destinations with per-destination isolation. One inbound event fans out to every consumer that needs it; a downed destination doesn't back-pressure the others. See Fan-out.
Replay from stored history. Every raw payload is kept. When you fix a bug, Replay re-runs the original event through the current pipeline — you don't ask the vendor to re-send.
Auditable delivery log per attempt. For every attempt to every destination: response code, body, timing, retry count. That's the evidence you need to answer "did this event actually land?"

The short version: webhook.site is where you catch a webhook once to look at it. Slashbin is where a webhook lives on its way to production destinations.

When to use which

Quick test — is this vendor even sending anything? → webhook.site. Faster to answer that question than anything else.
Local development against a live sender. → webhook.site + whcli forward to your laptop. Slashbin is overkill for a dev-loop scratchpad.
A production pipeline you rely on tomorrow. → Slashbin. Retries, replay, transform, fan-out, and a delivery log survive incidents; a disposable URL doesn't.
You need to prove what happened three weeks ago. → Slashbin. Stored payload, stored transform result, stored delivery attempts.
You need to deliver one event to several destinations without writing a router. → Slashbin. Fan-out is a first-class concept.

Many teams use both — webhook.site during vendor onboarding, Slashbin once the integration is real.

Feature comparison

Verified against the current webhook.site site and docs (2026-07-21).

Capability	webhook.site	Slashbin
Instant inspection URL, no signup	Yes	No — account required
Free-tier URL expiry	7 days	No expiry — a Free plan endpoint lives as long as the account
Free-tier request limit	100 requests per URL	1,000 webhooks/mo on the Free plan
Persistent URL that never expires	Paid	Yes
Custom domains	Paid	Not offered today
Transform / reshape payload against a schema	Paid Custom Actions	Yes — Golden Model
Deliver one event to N destinations with per-destination filters	Chain HTTP actions manually	Yes — Fan-out
Retries with backoff and dead-letter queue	Not the product model	Yes
Replay a stored raw payload through the current pipeline	Not the product model	Yes — Replay
Per-attempt delivery log (response code, body, timing)	Not the product model	Yes

"Not the product model" means the tool isn't trying to do that job — webhook.site is a capture-and-inspect surface (with optional forwarding actions), not a delivery gateway. It's not a knock on webhook.site; it's a different shape of product.