Sume webhook secret rotation: why the header has two sume-v1 entries
During a signing-secret rotation Sume sends one sume-v1 entry per live secret, newest first, comma separated. Accept the delivery if any entry matches.
During a signing-secret rotation the signature header carries one entry per live secret, newest first, separated by commas: sume-v1=<new>,sume-v1=<previous>. Accept the delivery when any entry matches (read 2026-10-06 in the webhook docs).
How should a receiver handle it?
Split the header on commas, trim each entry, ignore any that do not start with sume-v1=, and compare each against your expected digest.
What should I do in practice?
A verifier that reads only one entry will fail during the rotation window.
- Compare every entry so timing does not reveal which one matched.
- Do not take only the first entry.
- Deploy the new secret to your receiver before you rely on it.
Sources
Related posts
More in Developers
- Sume webhook Send test vs Redeliver: they are not the same
Send test posts a dummy signed webhook.test payload to a URL you type. Redeliver re-sends a real job's terminal event. Pick the right one for the job.
- Sume webhook signature header: why a sume-v2 entry is skipped
A Sume webhook verifier should compare only sume-v1= entries from the comma-separated header and skip other prefixes. Here is a Python check with a test.
- Sume webhook signature mismatch? Check the secret fingerprint header
Each Sume delivery carries x-sume-webhook-secret-fingerprint. Compare it with the dashboard before debugging code. Python verifier that refuses an empty secret.
- Sume webhook secret is per workspace: read it with account:read
Sume derives the webhook signing secret per workspace, not as a shared platform value. Read it on the dashboard or with GET /v1/webhooks/signing-secret.
Written by Sume