Rotating a webhook secret during a gradual deployment
Sume signs with both the new and old secret for 24 hours after rotation, so two receiver versions can run side by side. Upgrade the verifier first, then rotate.

Yes, rotation can overlap a gradual deployment. For 24 hours after you rotate, Sume signs every delivery with both the new and old secret, so a receiver version holding either one still verifies. Upgrade the verifier before you rotate, then roll out the new secret.
Sume details are from Verifying webhooks, read 2026-09-30. Cloudflare's changelog describes how a gradual deployment appears in Workers Metrics; it says nothing about secrets, so the pairing here is an inference.
Why does a gradual deployment need an overlap?
Cloudflare's entry says a gradual deployment shows as one rollout, shading more as traffic shifts to the new version. For that stretch two receiver versions serve traffic. With one signature, a version holding the other secret rejects its share of deliveries.
What does each rollout step look like?
Cloudflare's entry says a rollout step records the traffic percentage configured at that step. Map your steps onto the window like this; the stages are my illustration, not from either vendor.
| Stage | Receivers holding the old secret | Do the deliveries verify? |
|---|---|---|
| Before rotating | All of them | Yes, one signature |
| Rotated, 10% on the new secret | 90% | Yes: the header carries both entries |
| 50% on the new secret | 50% | Yes, while the window is open |
| 100% on the new secret | None | Yes; the old entry is now spare |
| Window closes with a step unfinished | Any left behind | No: the old secret stops verifying |
In what order should I do it?
First, make sure every receiver version verifies a multi-signature header. The docs warn that a hand-rolled check comparing the header for equality fails on every delivery during the window, and that verifyWebhook in @sume-com/sdk 0.2.0 already handles it. Second, rotate. Third, ship the new secret through your gradual rollout. Finish before the deadline, which the dashboard shows and rotation.previous_valid_until carries in the API responses.
Plan the rollout to fit well inside 24 hours. A rollout that you pause overnight at 50% is the case the window does not cover, so budget for the pause or rotate again later.
What if the secret leaked?
The window keeps the old secret valid, which is the point of a gradual rollout and the opposite of what a leak needs. The docs say rotating twice inside one window retires the secret from two rotations back immediately, which is what makes a leak stop. Weigh that against a half-finished rollout before you press the button a second time.
Sources
Related posts
More in Developers
- Grok Imagine first and last frame: keyframes on xAI only
xAI takes up to 4 timestamped keyframes for Grok Imagine video. Sume's grok-imagine-video-1.5 row takes one start image and rejects an end frame.
- Grok Imagine: how many images per request, xAI vs Sume
xAI's image API takes n from 1 to 10 per request. Sume's catalog code gives Grok a maximum of 1, so send one image per call and loop for more.
- Grok Imagine video length: 1-15 s on xAI, 4-15 s on Sume
xAI allows 1 to 15 seconds for grok-imagine-video-1.5. Sume's catalog row allows 4 to 15, so a 2-second clip needs another id such as wan-3.0.
- HeyGen API key permissions: /v3/api_keys/self vs Sume /v1/me
HeyGen's GET /v3/api_keys/self shows a key's name, scopes and expiry. On Sume, GET /v1/me verifies the key and returns non-secret account metadata.
Written by Sume