The Webhook Headers Every Major Provider Sends (Cheat Sheet)
A reference of the headers used by Stripe, GitHub, Shopify, Twilio, Slack, Plaid, Square, and more — including event ID, signature, event type, and the quirks for each.
The Cheat Sheet
When you're debugging a webhook, the first thing you usually want to know is "which event is this and how do I verify it." Every provider exposes that information differently. This is a quick reference.
Payment & Billing
| Provider | Event ID | Event Type | Signature |
|----------|----------|------------|-----------|
| Stripe | event.id (in body) | event.type (in body) | Stripe-Signature |
| PayPal | Paypal-Transmission-Id | event_type (body) | Paypal-Transmission-Sig |
| Square | Square-Initial-Delivery-Timestamp | event.type (body) | x-square-hmacsha256-signature |
| Adyen | pspReference (body) | eventCode (body) | hmacSignature (body) |
| Razorpay | x-razorpay-event-id | event (body) | x-razorpay-signature |
Developer Tools
| Provider | Event ID | Event Type | Signature |
|----------|----------|------------|-----------|
| GitHub | X-GitHub-Delivery | X-GitHub-Event | X-Hub-Signature-256 |
| GitLab | (none) | X-Gitlab-Event | X-Gitlab-Token (shared secret) |
| Bitbucket | X-Request-UUID | X-Event-Key | X-Hub-Signature |
| Linear | (in body) | (in body) | Linear-Signature |
Communication
| Provider | Event ID | Event Type | Signature |
|----------|----------|------------|-----------|
| Slack | X-Slack-Request-Timestamp + body | event.type (body) | X-Slack-Signature |
| Twilio | MessageSid (body) | (varies by webhook) | X-Twilio-Signature |
| SendGrid | (event ID per item in body) | event (body item) | X-Twilio-Email-Event-Webhook-Signature |
| Discord | (none, interactions use IDs) | type (body) | X-Signature-Ed25519 + X-Signature-Timestamp |
Commerce & Identity
| Provider | Event ID | Event Type | Signature |
|----------|----------|------------|-----------|
| Shopify | X-Shopify-Webhook-Id | X-Shopify-Topic | X-Shopify-Hmac-Sha256 |
| WooCommerce | X-WC-Webhook-Delivery-ID | X-WC-Webhook-Topic | X-WC-Webhook-Signature |
| Clerk | svix-id | type (body) | svix-signature |
| Auth0 | (in body) | (in body) | (none by default; signed log streams use HMAC) |
| Plaid | (in body) | webhook_type + webhook_code (body) | Plaid-Verification (JWT) |
CRM & Productivity
| Provider | Event ID | Event Type | Signature |
|----------|----------|------------|-----------|
| HubSpot | eventId (body) | subscriptionType (body) | X-HubSpot-Signature-V3 |
| Salesforce | (in body) | (varies by topic) | (depends on platform) |
| Calendly | (in body) | event (body) | Calendly-Webhook-Signature |
| Notion | (in body) | (in body) | X-Notion-Signature |
The Quirks Worth Knowing
Stripe's signature header packs multiple values. Stripe-Signature looks like t=1234567890,v1=abc...,v0=xyz.... You parse it, take the v1 value, and HMAC {timestamp}.{body} (note the dot).
Slack signs the timestamp. Slack requires you to verify a timestamp + body combination, AND reject requests where the timestamp is more than 5 minutes old. Replay protection is built into the spec.
Discord uses Ed25519, not HMAC. Most providers use HMAC-SHA256. Discord uses Ed25519 public-key signatures. You'll need a different library.
Plaid signs with JWTs. The Plaid-Verification header is a JWT containing a hash of the body. You fetch a public key from Plaid, verify the JWT, then verify the body hash matches.
GitLab uses a shared secret token, not HMAC. X-Gitlab-Token is just the secret you configured, sent in plaintext. This is weaker than HMAC and means anyone who sees one request can replay it. Use HTTPS only.
Shopify base64s the HMAC. Most providers use hex. Shopify uses base64. Easy to get wrong on the first try.
HubSpot includes the request method and URI in the hash. v3 signature is HMAC-SHA256 over {method}{uri}{body}{timestamp}. Missing any component breaks verification.
Why Have a Cheat Sheet at All
When you only deal with one provider, you internalize its quirks and never think about them again. The moment you handle two or more, you have to keep these details in your head — and they're easy to confuse mid-debug.
If you're integrating more than two webhook providers, the better long-term answer is to use a relay that normalizes them into one consistent format. Hookbase verifies the provider's signature, then forwards to your handler with a single X-Hookbase-Signature and a normalized event envelope. You learn one signing scheme instead of twenty.