webhook.co vs webhook.site
webhook.site gives you a URL before you have finished deciding you need one. That is a genuinely excellent property, and it is bought by treating captures as disposable — which is fine right up until the moment they are not.
Claims about webhook.site verified against their own documentation on . Sources below.
webhook.co is pre-launch. Our prices and retention windows below are published, not yet purchasable.
Why people compare these two
The version of this that stings is a Monday. Something broke over the weekend, you go back to the URL you were debugging with, and the free tier has already deleted it — the data and the URL both, on a seven-day clock that runs whether or not you are watching. The other one is a security review, where someone notices that a free capture has no login in front of it, and that anything a provider sent — including whatever was in those payloads — has been readable by anyone holding the URL's id.
These two tools disagree about what a captured request is. webhook.site treats it as something you are looking at right now — a bin, brilliantly executed, with an automation engine bolted on that is genuinely more capable than ours. We treat it as a record: something with an owner, a retention window, an audit trail, and an expectation that you will come back to it. Neither view is wrong, and the free tiers make the difference concrete rather than philosophical. Theirs deletes the URL and its data after seven days and puts no login in front of it. Ours is private by default, keeps captures for seven days on the free tier and longer on paid plans, and never hands the endpoint to whoever guesses the id.
At a glance
| Capability | webhook.site | webhook.co |
|---|---|---|
| Free tier retention | URL and data removed after 7 days | 7 days, and the ingest URL does not expire |
| Free captures private by default | No — no login; readable by anyone with the URL id | Yes, at every tier |
| Longest retention on a paid plan | 365 days maximum, and the latest 10,000 requests on Pro (100,000 on Enterprise) | 90 days on Scale; longer is negotiated |
| Built-in per-provider signature verification | No — hand-written in WebhookScript, and paid-only | 141 providers, Apache-2.0 |
| Entry paid plan | $9/month, or $90/year | €19/month |
| Self-hostable inspector | Yes — MIT, without the custom-actions layer | Yes — Apache-2.0 |
| No-code automation on captured requests | Yes — dozens of action types plus a scripting language | No |
The seven-day clock, and what a paid plan actually changes
On the free tier a URL and everything sent to it are removed after seven days. That number is stated on webhook.site's own FAQ, repeated in their plan comparison table, and repeated again in their own blog, so it is about as well established as a competitor fact gets. Paying changes the shape of the problem rather than removing it: URLs on a paid account stop expiring, but data is still purged at a maximum of 365 days, and a Pro URL keeps only its most recent 10,000 requests with older ones rotated out. If you are chasing a bug that reproduces once a fortnight, the free clock is the thing that will beat you.
Who can read your captures
webhook.site is unusually straight about this in its own documentation: the free version operates without a login, so data is accessible to anyone who knows the id of the URL. For pasting a test request around, that is a feature — it is why sharing a debugging session with a colleague is a copy and a paste. It stops being a feature the moment a provider sends something real down that URL, because provider webhooks routinely carry customer email addresses, order contents and payment metadata. Paid URLs are login-protected by default. Ours are private by default at every tier, including free, and re-displaying an ingest URL is a separate write-scoped action that lands in an append-only audit log.
Signature verification: written by you, or shipped with the tool
webhook.site can verify a signature, and we should be precise about how. Their documented path is a WebhookScript custom action calling hmac() with an algorithm and a secret, compared against a header you name yourself, returning 401 when it does not match. That is a real capability and a flexible one — but you are writing the verification, per URL, and custom actions are not available on the free tier at all. We ship verification for 141 providers as code you can read, and you can check a captured signature by hand in the browser without an account at all.
Where they are simply deeper than us
It would be dishonest to write this page without saying that webhook.site's automation layer is the more capable product. Their action catalogue runs to dozens of types — HTTP requests, SMTP and SSH, FTP upload and download, database queries, S3 and CloudFront, Google Sheets, Excel, Dropbox, RabbitMQ, PDF generation and image resizing, plus JavaScript and their own WebhookScript language, with conditions, variables and rate limiting. You can build a working integration in their UI without deploying anything. We have nothing like it and are not building it: our answer to what happens next is that the event goes to your code, or to your agent over MCP.
What webhook.site does better
Speed to a URL, and it is not close — the URL exists the moment the page loads, with no account, no install and no configuration. The automation layer described above is a genuinely deep no-code product that will save you writing a service you did not want to write. You also get an email address and a DNS name alongside the HTTP URL off the same token, which is unusually complete and very handy when you are testing something that might arrive by any of the three. And the self-hosted version is MIT-licensed with a Docker or Helm deploy, if you want the inspector on your own infrastructure. For throwaway debugging, sharing a request with a colleague, or mocking a response, reaching for it first is the correct instinct.
Where we fit instead
When a capture needs to still exist next month, belong to someone, and be private without paying for privacy. When you want the request forwarded to a port on your machine and replayed as often as you like while you fix the handler. And when the same events need to reach your code and your agents through one contract rather than through a UI.
Moving from webhook.site
Keep using it for what it is good at
This is not a migration that has to be total, and we would not pretend otherwise. Plenty of people should keep a webhook.site tab open for throwaway inspection and move only the endpoints that matter — the ones a provider is configured against, the ones a colleague might need to look at in a month.
What maps onto what
A webhook.site URL becomes an endpoint with a permanent ingest URL. Their request list becomes your events list, with the same read-it-and-replay-it loop. A custom action that forwarded a request to your server becomes a destination with retries and a dead-letter queue behind it. A custom action that did anything cleverer than forwarding does not map, and that is the honest boundary of this comparison.
Take anything you still need first
There is no importer, and the seven-day clock is unforgiving, so anything you want to keep should come out before you stop looking. CSV export is a paid feature on their side; on a free URL, the practical answer is to copy what matters out by hand while it is still there.
Questions about webhook.site and webhook.co
How long does webhook.site keep free requests?
Seven days, after which the URL and its data are both removed. That figure appears on webhook.site's FAQ, in their plan comparison table and in their own blog, so it is unambiguous. On a paid account URLs stop expiring, but data is still purged at a maximum of 365 days.
Is data sent to a free webhook.site URL private?
No. Their documentation states that the free version operates without a login, so the data is accessible to anyone who knows the id of the URL. URLs on a paid subscription are login-protected by default. Treat a free URL as public and never point live provider traffic at one.
Can webhook.site check a provider's signature for me?
Not as a built-in per-provider feature. It gives you an hmac() function inside a WebhookScript custom action, so you write the verification yourself against a header you specify. Custom actions are not included on the free tier.
Is webhook.site open source?
The inspector is, under the MIT licence, and can be self-hosted with Docker or Helm. Their documentation is explicit that the self-hosted build does not include the Pro custom-actions layer, so the automation features are not part of what you can run yourself.
Sources, and how to correct us
Every claim above about webhook.site was read off the pages below on the date shown, not from memory. Products change faster than pages do — if something here is wrong or out of date, including if you work at webhook.site, tell us and we'll fix it.
Other comparisons
Point a webhook at it. Watch it land.
Start free: a permanent URL, full inspection, one-command replay — and outbound delivery, because every feature is on every plan. Move up when you need more events.