Credentials stripped before anything is stored
See exactly what your webhook sent
Get a URL, point anything at it, and read every header and byte that arrived. Credentials and personal data are stripped before anything is written to disk — and if that is not enough, the payloads can be encrypted to a key that only your browser holds.
Free tier · No account · No card
Why not just use any webhook tester?
Because of what you have to send it. A webhook from Stripe, GitHub, Shopify or your own staging environment carries a signing secret in a header, an API key in a payload, a customer's email address, sometimes a card's last four digits. A tester that stores the request verbatim now holds all of that, on somebody else's server, usually with a public URL that anybody who guesses the id can read.
This one redacts first. Authorization, Cookie, every
X-*-Signature header, private keys, JWTs, AWS and GitHub and Slack and
Stripe and OpenAI tokens, bearer and basic credentials, email addresses, and
anything with the shape and entropy of a secret are replaced with a marker that says
what was removed. The redaction happens in the request that received the payload, so
the unredacted bytes are never written anywhere — not to a row that gets cleaned up
afterwards, not to a log.
What a captured request looks like
You get the method, the path, the query string, every header as it was sent (so you
can see whether the sender used X-Hub-Signature or
X-Hub-Signature-256), the body pretty-printed when it is JSON and byte
for byte when it is not, the size, and the time. Alongside it, a line saying what
was redacted and how many times — so a missing value is never a mystery.
Encryption, for when redaction is not enough
Redaction removes what we can recognise. It cannot promise anything about a field we did not know to look for. So an endpoint can be created with a keypair your browser generates: the public half comes to us, the private half stays in the URL fragment, and every payload is sealed to it with ECDH on P-256 and AES-256-GCM before it is stored. The server can write your payloads and cannot read them back. There is no recovery if you lose the link, which is the point rather than an oversight.
Who can see your captures
The URL you give the sender is also the URL you read on, so anybody who has that URL can read what arrived — and it ends up pasted into a Stripe dashboard, a GitHub settings page, a CI log. Every inspector of this kind works that way, and most of them do not mention it.
That is exactly what the encryption option is for. The key lives after the
# in your own address bar, which is not part of the URL a server ever
receives and not part of what you pasted anywhere. Somebody who finds your capture
URL gets a list of payloads they cannot open.
Free, and what the paid plans add
The free plan gives you one endpoint, 7 days of retention and 100 requests, with no account at all. Paid plans raise all three, keep endpoints alive longer and let you write your own redaction rules. Redaction and encryption are on every plan, including the free one — they are the product, not an upsell.
Webhook Inspector
See exactly what your webhook sent
Point Stripe, GitHub or your own staging environment at a URL we give you, and read what arrived. Credentials are stripped before anything is stored.
Free tier · No account · No card