HeyGen webhook secret shown once: rotation vs Sume's reveal

HeyGen shows a webhook signing secret only when you create an endpoint or rotate its secret, and the old secret stops working the moment you rotate. Sume lets you read the workspace signing secret again from the dashboard or from GET /v1/webhooks/signing-secret, and during a rotation its signature header carries one entry per live secret, so a receiver that accepts either one never drops a delivery.

HeyGen's behavior is from its Create Webhook Endpoint and Webhooks pages (read 2026-10-10). Sume's is from Webhooks.

Two models of a secret

The practical difference is whether a lost secret is a re-read or a re-issue.

What immediate invalidation costs you

With HeyGen, a rotation is a cut-over. Between the moment you rotate and the moment your receiver loads the new secret, deliveries signed with the new secret fail your old check,. The safe sequence is to store the new secret first, deploy, and only then treat old-secret failures as bugs.

HeyGen's page does not describe an overlap period, so plan the cut-over as a short, deliberate event: rotate during a quiet hour, and check the endpoint's recent deliveries afterwards.

Sume's overlap removes that window. While two secrets are live, every delivery carries both signatures, newest first, comma separated. Your verifier loops over the entries and compares each one in constant time, so timing does not reveal which entry matched. The Sume docs include a TypeScript verifier that does exactly this.

The fingerprint trick

When a signature will not verify, you do not need to paste a secret anywhere to find out why. Every Sume delivery carries x-sume-webhook-secret-fingerprint, and the dashboard shows the fingerprint next to the secret. If the two differ, your receiver holds a stale secret. If they match, look at the body instead: a framework that re-serializes JSON changes the bytes and breaks an HMAC over the raw body.

HeyGen's page makes the same raw-body point: verify against the raw body bytes, not a re-serialized object, and compare in constant time.

Checklist for either vendor

• Keep the secret in an environment variable or a secret manager, never in a repository, and refuse to run the verifier with an empty value.
• Test the verifier with a known-good body and a deliberately wrong secret, so you see both a pass and a fail before the first real event.
• Write down who can rotate it and what the rollout order is before you need it.
• Verify the signature before parsing or acting on the payload.
• Deduplicate on the job or video id, because both vendors can deliver the same event more than once.
• For avatar clips, keep polling GET /v1/jobs/{id}/status as a backup path, as the Sume page advises.

Using it with Sume avatar jobs

An avatar video submitted with mode: "webhook" signs its terminal event with the workspace secret, the same one that Run webhooks use, so a single verifier and a single rotation procedure cover both. The delivery also carries x-sume-webhook-timestamp, and the docs suggest rejecting anything outside a five-minute window.