What is Standard Webhooks?
Standard Webhooks is an open spec (standardwebhooks.com) that defines a consistent header format for webhook signing and replay protection across providers. The goal: stop every provider from inventing their own signing scheme. Several modern providers — Clerk, Resend, and others — already follow it.
What the spec standardizes
Three things, expressed as a small set of HTTP headers:
webhook-id— a unique identifier per webhook delivery, used for idempotency on the receiving sidewebhook-timestamp— Unix timestamp when the webhook was sent, used for replay-attack protectionwebhook-signature—v1,base64(hmac_sha256(secret, "{webhook-id}.{webhook-timestamp}.{raw-body}")), used for sender verification
The signature can contain multiple space-separated values during secret rotation, so receivers accept any matching signature. This is how rotation overlap works without dropping events.
Why this matters
Without a standard, every provider invents their own signing scheme — Stripe's t=...,v1=..., GitHub's X-Hub-Signature-256, Shopify's base64 HMAC, Slack's v0: prefix, Twilio's URL+sorted-form-fields HMAC-SHA1. Receivers write a different verification function for each one.
Standard Webhooks lets receivers write one verification function and use it across every Standard-Webhooks-compatible provider. As more providers adopt the spec, the integration burden shrinks.
Hooksbase and Standard Webhooks
Hooksbase signs every outbound dispatch with Standard Webhooks-compatible headers. Your destination handler can use any Standard Webhooks library to verify, and the same code works whether the source was a verified provider or a custom producer.
Two of the five Hooksbase pre-verified providers (Clerk, Resend) use Standard Webhooks natively for their inbound signing. Polar (covered by a guide) also follows the spec.
For the broader signing context: HMAC.
Frequently asked questions
Which headers does Standard Webhooks define?
Three: webhook-id, a unique identifier per delivery used for idempotency on the receiving side; webhook-timestamp, used for replay-attack protection; and webhook-signature, a v1 prefix followed by the base64 HMAC-SHA256 over the id, timestamp and raw body. The signature field can hold several space-separated values, which is how secret rotation overlaps without dropping events.
Does Hooksbase follow Standard Webhooks?
Yes. Every outbound dispatch is signed with Standard Webhooks-compatible headers, so one verification function works whether the source was a pre-verified provider or a custom producer. Two of the five pre-verified providers, Clerk and Resend, use the spec natively on the way in.
What is Hooksbase?
Hooksbase is event infrastructure for AI agents. It ingests events over four channels — HTTP, email, HTML form, and scheduled cron — verifies them, routes them by rule, runs versioned Automations in the event path, and delivers them to HTTP and cloud destinations (AWS SQS, AWS EventBridge, GCP Pub/Sub, and S3-compatible storage) with retries, strict ordering, Standard Webhooks-compatible signing, deterministic replay, and a dead-letter path. It is a hosted service, runs on Cloudflare Workers, is operated at hooksbase.com, and is not affiliated with — and shares no code or ownership with — other similarly named webhook, hook, or tunnelling tools.
Related terms
- Webhook
An HTTP request one service sends to another to notify it that something happened.
Read - HMAC
Hash-based Message Authentication Code — proves a message came from someone who knows a shared secret and was not modified.
Read - Idempotency
A property where performing an operation multiple times produces the same result as performing it once.
Read - Strict FIFO
Per-webhook ordering mode where the head delivery blocks subsequent ones until it succeeds or terminally fails.
Read