missing_signature_header

Summary

What caused it

The provider adapter looked for its expected signature header (Stripe-Signature for Stripe, X-Hub-Signature-256 for GitHub, X-Shopify-Hmac-Sha256 for Shopify, and so on — see the full list on Supported providers) and it wasn't present on the request at all.

This almost always means the request didn't actually come from the provider it's addressed to. Common causes:

• Health checks or uptime monitors hitting the webhook URL directly, which send plain GET/POST requests with no provider-specific headers.
• Browser or scanner traffic — automated scanners probe common paths like /webhooks/stripe looking for misconfigured endpoints.
• A reverse proxy, CDN, or WAF stripping custom headers before the request reaches your app. Some default CDN configurations only forward a fixed allowlist of headers.
• The wrong URL registered in the provider's dashboard — e.g. pointing Stripe at a Slack-handling route by mistake, so the header the code looks for is never the one that provider actually sends.

The fix

If the traffic is expected to be non-provider traffic (health checks, monitoring), route it to a separate endpoint rather than your webhook URL, or accept that a 400 is the correct response — there's no fix needed for hooksentinel's behavior here, since it's correctly rejecting a request that isn't a valid webhook delivery.

If you believe this is genuine provider traffic, check your infrastructure for header stripping:

# from your origin server, confirm the header arrives through your proxy/CDN
curl -sv -X POST https://your-app.example.com/webhooks/stripe \
  -H "Stripe-Signature: t=1,v1=test" \
  -H "Content-Type: application/json" \
  -d '{}' 2>&1 | grep -i stripe-signature

If the header doesn't appear on your origin's access logs but you can confirm (via the provider's dashboard delivery logs) that it was sent, the header is being dropped somewhere between the provider and your app — check CDN/WAF header allowlists and any API gateway header-filtering rules.

Double check the registered URL in the provider's dashboard matches the route mounted with the correct provider adapter — a mismatch here produces exactly this error, since a request from Provider A hitting a route configured for Provider B will never carry the header the code is looking for.