Sume job webhook_delivery: attempts, exhausted, redeliveries

A job created with a webhook_url carries a webhook_delivery object that tells you whether the callback arrived: status, attempts against max_attempts, last_status_code, last_error, and manual_redeliveries. The documented ceiling is 10 automatic attempts, 10 seconds per attempt, with a fixed delay (30 seconds by default) between them. When delivery is exhausted, the job still reached its real terminal state; read it from the job and redeliver.

Field names come from the WebhookDelivery schema in the API reference; the retry numbers come from Webhooks. Both read 2026-10-02.

What fields does webhook_delivery have?

The object is on GET /v1/jobs/{id} (data.job.webhook_delivery) and is null on jobs without a webhook.

What do the retry numbers mean?

The webhooks page says non-2xx responses and network errors are retried up to 10 attempts total, with a fixed delay between attempts (30 seconds by default), not exponential backoff, and a 10 second timeout per attempt. A slow endpoint burns the budget and gets retried, so return a 2xx fast after durably storing the event, and do the work afterwards.

Use job_id as your idempotency key on the receiving side: retries and redeliveries can send the same event more than once.

What do I do when status is exhausted?

Ten refused attempts leave a failed delivery and a job that is still in its real terminal state. Fix your endpoint, then call POST /v1/jobs/{job_id}/webhook/redeliver (scope jobs:write). Sume re-sends the job's real terminal event with a fresh timestamp and signature. The docs say this still works after automatic attempts are exhausted and does not consume one of the automatic 10; it increments manual_redeliveries.

If you would rather not wait for a delivery at all, polling stays available: webhooks are an optimization, not your only recovery path.

How do I find out why an attempt failed?

Work down this list; each step is a read, not a resubmit.

• Read last_status_code and last_error first; they are the last attempt's result.
• Compare signing_secret_fingerprint with the fingerprint shown beside your secret in the dashboard. If they differ, your verifier holds a different secret; neither side has to quote the secret itself.
• Read GET /v1/jobs/{id}/events; webhook.delivery is one of the public event types.
• Redeliver is not Send test: Send test posts a dummy webhook.test payload to a URL you type and never replays a real job.