Standard Webhooks webhooks

Q: How do I verify a Standard Webhooks webhook?

HMAC-SHA256 over id.timestamp.body , base64-encoded, with a tolerance window. The same scheme HookGet uses on the way out. With HookGet you do not implement it: the source is created with a secret, and every request is checked against webhook-id , webhook-timestamp , webhook-signature before the event exists.

Q: What happens if Standard Webhooks sends the same event twice?

Redeliveries are deduplicated on webhook-id , namespaced per source, so a repeat becomes the same event rather than a second one.

Anything on the open Standard Webhooks specification, including Svix-sent traffic.

In short

Verification: the provider’s own HMAC signature over the raw body.
Deduplication: webhook-id.
Once verified, the event joins your catalogue with the same retries, log and replay as anything you publish yourself.

The contract

Field	Value
Provider key	`standard-webhooks`
Header checked	`webhook-id`, `webhook-timestamp`, `webhook-signature`
Scheme	HMAC-SHA256 over `id.timestamp.body`, base64-encoded, with a tolerance window. The same scheme HookGet uses on the way out.
Deduplicated on	`webhook-id`
Event type	The `type` field is used as-is.

Setting it up

# 1. create a verified source; the secret is shown once
curl -X POST https://api.hookget.com/v1/sources \
  -H "authorization: Bearer $HOOKGET_KEY" \
  -H "content-type: application/json" \
  -d '{"provider":"standard-webhooks","name":"Production"}'

# {"id":"src_…","secret":"whsec_…","ingest_path":"/ingest/src_…"}

Point the sender at the ingest URL and give it the source secret.
No translation is needed: this is the same specification HookGet signs with.

Worth knowing. If you are consolidating several senders on this spec, give each one its own source. Secrets rotate independently and the dedupe key is namespaced per source.

What you get after verification

The event appears in your log with a namespaced type, so Standard Webhooks traffic never collides with your own.
It fans out to your destinations with the same retry schedule and dead-letter behaviour as any other event.
The source secret rotates with an overlap window, so you can update Standard Webhooks at your own pace.
Each inbound source is rate limited on its own, so a busy provider cannot exhaust your publish budget.

Questions

How do I verify a Standard Webhooks webhook?

HMAC-SHA256 over id.timestamp.body, base64-encoded, with a tolerance window. The same scheme HookGet uses on the way out. With HookGet you do not implement it: the source is created with a secret, and every request is checked against webhook-id, webhook-timestamp, webhook-signature before the event exists.

What happens if Standard Webhooks sends the same event twice?

Redeliveries are deduplicated on webhook-id, namespaced per source, so a repeat becomes the same event rather than a second one.

What if verification fails?

The request is refused with 401 and nothing enters the pipeline. The rejection is logged on our side as a signal worth watching; the caller learns nothing beyond the status.