Skip to main content
The 144 providers webhook.co verifies, generated from the same registry the engine runs. Find your sender, register a provider secret under its slug, and verification runs automatically — see how verification works. Columns: the provider, the slug you register the secret under, the signature scheme (HMAC digest is SHA-256 unless noted), the exact signature header, and whether the provider uses a setup handshake (answered automatically). A handful of providers carry the signature in the request body or a form field rather than a header — noted inline.
Most providers take a single signing_secret (the default kind, so you can omit it). Three handshake-and-key cases take an extra kind: Meta and eBay accept a verify_token for their challenge, and Braintree accepts a braintree_public_key alongside its signing secret. See managing provider secrets.

Standard Webhooks

The open Standard Webhooks construction: HMAC-SHA256 over {id}.{ts}.{body}, base64, secret decoded from a whsec_-prefixed key. If your sender implements this spec, this family is the one to match.

HMAC over the raw body

The signature is computed over the exact request body verbatim — the most common scheme. Digest is SHA-256 unless the row says otherwise.

HMAC with a signed timestamp

The signed message includes a timestamp (from a header or a field inside the signature header), so the signature also fences a replay window. Digest is SHA-256 unless noted.

HMAC over request context

These sign more than the body — the request URL, sorted form fields, specific JSON fields, or a manifest. Some carry the signature in the body or a form field rather than a header.

JWT (HS256)

The signature is a JWT signed with a shared secret. Some bind the body via a hash claim; others prove origin, destination, and freshness without hashing the body.

Asymmetric signatures

Public-key verification — you register the provider’s public key (or, for remote-key providers, an issuer URL or app credentials the engine uses to fetch the key). Nothing you hold can forge one of these.

Token / HTTP Basic

These don’t sign the payload — they prove the source with a shared static token or HTTP Basic credential. A match is real but weaker than a signature, so verified events land in the authenticated state, never verified. Where the header is operator-configured, you register the header name alongside the token.

Not seeing your provider?

Capture works for any sender regardless — and an unlisted provider is often one step away. See custom or unlisted provider.