Sending events in

Inbound verification

You don't write any code for inbound verification — Webhooker does it for you. Set a source's scheme and secret once in the dashboard, and every request that comes in is checked before it's accepted.

How it works

When you configure a source's verification (for example Stripe's or GitHub's HMAC-SHA256 / SHA1 scheme and secret), Webhooker checks every incoming request's signature against it. Requests that fail are rejected with 401 and never enter the delivery pipeline, so forged payloads can't reach your services. The event is still stored for your audit trail, but it's marked invalid and isn't delivered.

Why it matters

A webhook URL is public by nature — anyone who learns it can POST to it. Verifying the provider's signature is what separates a real event from something an attacker sent. Because Webhooker checks it at the edge, that guarantee holds for every destination on the source without you repeating the logic in each app.

Two different signatures

It's worth keeping the two directions straight:

Inbound — the provider's signature on the request coming into Webhooker. We verify this for you, as described above.
Outbound — Webhooker's signature on the delivery going out to your app. You verify this one, and only if you set a signing secret. See Verify our signature.

Doing it yourself

If you're verifying a provider's signature in your own code rather than letting Webhooker do it, each provider has its own scheme and its own pitfalls. These walkthroughs cover the ones we see most:

Verifying Stripe webhook signatures — the Stripe-Signature header, the t= timestamp, and why the raw body matters.
Verifying GitHub webhook signatures — X-Hub-Signature-256 and redeliveries.
Verifying Shopify webhooks — base64 HMAC plus the mandatory GDPR topics.
When verification fails — the six causes behind nearly every failed signature check.