Standard Webhooks headers vs Sume sume-v1: a header map

A stock Standard Webhooks verifier will not accept a Sume delivery as-is. Sume sends x-sume-webhook-timestamp and x-sume-webhook-signature: sume-v1=<hex_signature>, not the webhook-id, webhook-timestamp and webhook-signature trio. Verify with verifyWebhook from @sume-com/sdk.

Spec facts are from the Standard Webhooks page; Sume facts from Webhooks and Run webhooks, read 2026-09-30.

How do the headers map?

The spec prefixes every header with webhook- and uses a space-delimited signature list. Sume uses its own names and a comma-separated list.

What do I dedupe on without a webhook-id?

For job webhooks, use job_id as the idempotency key on your side. For run webhooks, request_id equals the run id and is the same on every retry: "Stable across retries — use it to dedupe." Use created_at to order deliveries, since request_id cannot. See request_id stable across retries.

Why does a Standard Webhooks library fail on it?

It looks for the webhook-* headers and the spec's signed content, neither of which Sume sends. The spec encodes its example signature as v1,<base64>; Sume encodes hex after sume-v1=. A mismatch on any of these makes verification fail even with the right secret.

Both sides agree on one rule: sign and verify the exact bytes. The spec warns that parsing the body as JSON and re-serializing it is a common cause of failed verification, and Sume's docs say the same about the raw body.

What should I use instead?

verifyWebhook is the check, so you do not write it. It takes the raw body, the headers and SUME_COM_WEBHOOK_SIGNING_SECRET, is async, and returns false instead of throwing. One verifier covers job and run webhooks because they share one secret. If you must adapt an existing pipeline, put a thin verification step in front that calls it and forwards only verified bodies. More hardening notes are in webhook security best practices.