Sume webhook signature will not verify: compare the fingerprint
Each Sume delivery has x-sume-webhook-secret-fingerprint. Compare it with the dashboard fingerprint to find a wrong secret without ever sending the secret.
Every Sume delivery carries x-sume-webhook-secret-fingerprint, and the receipt's webhook_delivery.signing_secret_fingerprint shows the same value. If a signature does not verify, compare it with the fingerprint next to the secret in the dashboard (read 2026-10-06).
How do I debug a mismatch?
A different fingerprint means your receiver holds the wrong secret. The same fingerprint means the problem is in how you build the signed string, usually a re-serialized body.
What should I do in practice?
The latter needs an API key with account:read.
- Neither side needs to send the secret itself.
- Sign
<timestamp>.<raw_body>exactly. - Read the secret from the Webhooks tab or
GET /v1/webhooks/signing-secret.
Sources
Related posts
More in Developers
- Sume webhook secret fingerprint header: check your secret safely
Every Sume run webhook carries x-sume-webhook-secret-fingerprint. Compare it to the receipt and dashboard fingerprint to catch a wrong secret before verifying.
- 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.
- 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.
Written by Sume