Sume webhook retry schedule: 10 attempts, then what?
Sume tries a webhook up to 10 times. Job webhooks use a fixed 30 s gap; run webhooks back off with jitter up to an hour. What happens next, and how to replay.

Sume attempts a webhook up to 10 times in total. For a job webhook the gap between attempts is fixed, 30 seconds by default, and not exponential. For a run webhook the gap backs off with jitter and is capped at one hour. After the tenth refused attempt the delivery is marked failed, the job or run keeps its real outcome, and you replay the delivery by hand.
This follows the Sume Webhooks and Run webhooks docs, read 2026-09-29.
How do job and run webhook retries differ?
There are two webhook surfaces. Job webhooks come from POST /v1/models/... or a model endpoint such as /v1/avatar-1.0/generate, sent with mode: "webhook" and emit job.completed, job.failed and job.canceled. Run webhooks come from Action, Format and Agent Completion runs and emit *.run.terminal. They share the signing secret and the attempt cap, but not the schedule.
| Job webhook | Run webhook | |
|---|---|---|
| Attempts | Up to 10 in total | Up to 10 in total |
| Spacing | Fixed delay, 30 s by default, not exponential | min(max(30s x 2^(attempt-1) with jitter, Retry-After), 1h) |
| Timeout per attempt | 10 s | 10 s |
| Success | Any 2xx | Any 2xx |
What counts as a failed attempt?
A network error or any non-2xx response is retried until attempts are exhausted. A slow endpoint burns the 10-second budget and gets retried too, so return 2xx quickly, after you have durably stored the event, and do your processing afterward. On run webhooks a redirect is not followed: a 3xx is a failed attempt. For run webhooks, 429 and 503 from your endpoint honor Retry-After, up to one hour.
What happens after the tenth attempt?
Ten refused attempts leave you with a failed delivery and a job that still reached its real terminal state. On a run the webhook_delivery.status becomes exhausted (or failed), with last_status_code and last_error saying why. Fetch the result from result_url, fix the endpoint, then redeliver.
Redeliver re-sends the real terminal event with a fresh timestamp and signature, and it does not consume one of the automatic 10. That means it still works after attempts are exhausted. Send test is a different control: it posts a dummy webhook.test body and never replays a real job.
# job webhook
curl -X POST https://api.sume.com/v1/jobs/job_123/webhook/redeliver \
-H "Authorization: Bearer $SUME_API_KEY"
# run webhook
curl -X POST https://api.sume.com/v1/format-runs/$RUN_ID/webhook/redeliver \
-H "Authorization: Bearer $SUME_API_KEY"How do I make retries harmless?
Dedupe. Use job_id as the idempotency key on your side for job webhooks; for run webhooks dedupe on request_id, which is the same value on every retry of the same run. Redeliver does not change the destination URL: a new URL is a new job.
Keep polling as the backup. The docs call a webhook a delivery optimization and never the only recovery path, so keep status_url polling available for events that never arrive.
Sources
Related posts
More in Developers
- Suno alternative with an API: what Sume's Music Router does
Looking for a music generator you can call from code? What Sume's Music Router takes in, returns and does not do, so you can decide if it fits.
- Talking avatar in JS: make one from Node, play it in React
A talking avatar in JavaScript: create it and send it a script from Node with the Sume SDK, wait for the job, then play the returned MP4 in React.
- Avatar video quality settings: standard, plus or max?
Sume's talking avatar video takes quality standard, plus (default) or max. What each means, the other output fields, and how the preview relates to final tier.
- Team API keys: which wallet does a Sume run charge?
A Sume run charges the workspace its API key belongs to. A team key spends the team wallet; a personal key on a team Format is refused with 403.
Written by Sume