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.

4 min readSume
All posts

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.

From Webhooks and Run webhooks, read 2026-09-29.
Job webhookRun webhook
AttemptsUp to 10 in totalUp to 10 in total
SpacingFixed delay, 30 s by default, not exponentialmin(max(30s x 2^(attempt-1) with jitter, Retry-After), 1h)
Timeout per attempt10 s10 s
SuccessAny 2xxAny 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

All Developers posts

Written by Sume