Redeliver a missed video webhook after a bad deploy: one Sume call

If a Sume video job finished while your webhook receiver was broken, call POST /v1/jobs/{job_id}/webhook/redeliver with a key that has the jobs:write scope. Sume re-POSTs the real terminal event (job.completed, job.failed or job.canceled) with a fresh timestamp and a fresh signature, even after the automatic attempts are used up. It does not count against the automatic ten.

This is the repair step for the most likely migration accident: you shipped a new receiver to replace the one that served your old Sora integration, got the route wrong for an afternoon, and now have finished videos nobody was told about.

Redeliver is not Send test

The dashboard offers two buttons that look alike. **Send test** posts a dummy signed webhook.test payload to a URL you type, with no job_id; it never replays a real job. **Redeliver** works per job and replays the real event. Use Send test to check your signature code; use Redeliver to recover a job.

Find what you missed

A job's webhook_delivery status uses six values: pending, delivering, delivered, retrying, failed and exhausted. List your video jobs, keep the ones whose delivery is failed or exhausted, and redeliver each. Events also show a webhook.delivery entry in GET /v1/jobs/{id}/events, which is where to look when you need the attempt history.

Because redelivery can arrive more than once, the receiver must dedupe on job_id. The docs call it your idempotency key. A second delivery of a job you already downloaded should return 2xx and do nothing.

What redeliver cannot fix

The destination is fixed at submit. If the job was created with a wrong callback_url, redelivery goes to the same wrong place. The docs say a new URL is a new job; do not resubmit a paid video to change a callback. Poll the job through GET /v1/jobs/{id}/status and /result instead, and take the artifact from there.

If a signature will not verify on the redelivered event, compare x-sume-webhook-secret-fingerprint with the fingerprint shown next to the secret in the dashboard. Neither side has to send the secret. The fingerprint post walks through it.

A recovery order that avoids double work

• Fix and deploy the receiver first. Confirm it with Send test.
• Query jobs whose webhook delivery is failed or exhausted.
• Redeliver them one at a time and watch the receiver log for each job_id.
• For any job still missing after that, read GET /v1/jobs/{id}/result directly.
• Never resubmit the paid generation just because a callback was lost.

Rate limits and the order of operations

Redelivering many jobs in one burst can run into the same request-volume limits as any other call. The docs say to use retry-after when a 429 carries it. Space the calls out, and let the receiver finish each delivery before sending the next so that a slow database does not turn recovery into a second outage.

Because a redelivered event carries a fresh timestamp, the replay-protection window passes. An event that was originally signed an hour ago arrives signed now. Do not widen your tolerance to make old events verify; ask for redelivery instead.