Webhook Validator: Provider-Aware, End-to-End
Debugging a webhook that seems malformed or unauthenticated usually means knowing exactly which provider's conventions apply — Stripe, GitHub, and Slack each sign and structure their webhooks differently. This tool detects the provider from your headers automatically, then applies that provider's exact verification algorithm.
Detection is based on the presence of each provider's distinctive signature header — Stripe, GitHub, and Slack all use different header names and signed-message formats.
One Tool, Three Signing Conventions
GitHub signs the raw payload alone. Stripe and Slack both fold a timestamp into the signed message (differently — Stripe uses `${t}.${payload}`, Slack uses `v0:${timestamp}:${payload}`) specifically to support replay-attack rejection. Rather than making you look up which formula applies, this tool detects the provider and applies the correct one automatically.
Structural Checks Run Regardless of Secret
Even without a signing secret, the tool validates that your payload is well-formed JSON and reports which provider it detected — useful for a first-pass sanity check before you have (or want to expose) the actual signing secret.
Practical Examples
Debugging a Slack Event Subscription
A Slack webhook handler is rejecting valid events.
- 1.Paste the raw payload and X-Slack-* headers
- 2.Enter your Slack signing secret
- 3.See whether the signature and timestamp freshness both check out
Providers Detected
- Stripe (Stripe-Signature)
- GitHub (X-Hub-Signature-256 / X-GitHub-Event)
- Slack (X-Slack-Signature + X-Slack-Request-Timestamp)
Good Use Cases
- Debugging webhook signature verification failures
- Confirming a payload is well-formed before deeper investigation
- Checking timestamp freshness for replay-attack protection
- Learning how a specific provider's webhook security works
Frequently Asked Questions
How does provider detection work?
It checks your pasted headers for provider-specific signature header names: Stripe-Signature for Stripe, X-Hub-Signature-256 or X-GitHub-Event for GitHub, and the pair X-Slack-Signature + X-Slack-Request-Timestamp for Slack — each provider's convention is distinct enough to identify reliably.
What happens without a signing secret?
The tool still validates that the payload is well-formed JSON and reports the detected provider, but skips signature verification since that requires the actual secret used to sign the payload.
How is each provider's signature actually verified?
Using the real algorithm each provider documents: Stripe and GitHub both use HMAC-SHA256 (Stripe over `${timestamp}.${payload}`, GitHub over the raw payload), while Slack uses HMAC-SHA256 over `v0:${timestamp}:${payload}` — all computed via the browser's native Web Crypto API.
Why does it check timestamp age for Stripe and Slack?
Both providers include a timestamp in their signed message specifically so receivers can reject old, potentially replayed requests — both recommend rejecting anything older than 5 minutes (300 seconds), which this tool checks and flags.
Is my secret sent anywhere?
No — signature verification happens entirely in your browser via the Web Crypto API; nothing is sent to a server.