Skip to main content
webhook.co checks incoming webhook signatures for you. Register a provider secret for an endpoint, and every captured event runs through that provider’s verification adapter over the exact bytes we received — the result is recorded as the event’s verification state. Verification is best-effort and runs after capture, so a bad signature never costs you the event; it just labels it.

​
Selection is driven by what you registered, not by headers

A signature header alone doesn’t tell us who sent something — plenty of providers reuse the same header name, and headers are trivially spoofable. So selection is registration-driven: for each provider you’ve registered a secret for on an endpoint, we run that provider’s adapter against the captured bytes. The first adapter to verify wins, and that’s what names the event’s provider. If two providers you registered happen to share a header shape, each gets a real cryptographic shot at the payload and the one whose secret actually validates is the one that sticks.

​
The four-value verification state

Every event carries exactly one of these:
  • verified — a cryptographic signature over the payload checked out. The strong state.
  • authenticated — the source proved itself with something weaker than a payload signature: a shared static token or HTTP Basic. It’s genuinely authenticated, but it isn’t a signature over this payload, so it’s a distinct, lesser state.
  • failed — a signature was checked and rejected. The event is still captured so you can see it, but it’s never delivered to a destination and never re-signed. A failed event is a red flag, not a dropped one.
  • unattempted — no signature was checked, because you haven’t registered a secret for a provider that matches. The event is still captured and still deliverable, but webhook.co won’t put its own signature on something it never authenticated.
That last distinction matters downstream: an unattempted event is delivered unsigned even to a destination configured for signing. webhook.co signs the events whose source it authenticated — verified and authenticated — and nothing weaker.

​
142 providers from one registry

Verification adapters come from a single registry covering 142 providers. Most — around 109 — are config-driven HMAC variants that differ only in header names, encodings, and what exactly goes into the signed string. The remaining 33 are bespoke: JWT-based schemes, asymmetric signatures (Ed25519, ECDSA, RSA), providers that require fetching a rotating public key, request-context signing, and the non-cryptographic token/Basic schemes that land in the authenticated state. Browse the full list in the provider directory. If a provider isn’t there, its events simply stay unattempted — captured and usable, just unsigned by us.

​
How provider secrets are handled

When you register a provider secret it’s sealed with KMS on arrival and bound, via additional authenticated data, to the specific org, endpoint, and secret it belongs to. That binding means a sealed secret can’t be lifted and replayed against a different endpoint — it only unseals in the context it was created for. The API and MCP surfaces relay ciphertext; only the delivery engine ever unseals it to run a verification. The contract for both inbound verification and outbound re-signing is Standard Webhooks, so what you verify coming in and what you can re-sign going out speak the same language.