Webhook send test vs redeliver: which one replays a real job?

Send test never replays real work: it posts a dummy signed webhook.test payload to a URL you type. Redeliver is the one that re-sends a real job or Format run, with a fresh timestamp and signature, and it does not consume one of the automatic 10 attempts.

What is the difference in one table?

Sume documents them as two different actions that you should not substitute for each other. The table lists what each one sends and what it needs.

When should I use Send test?

Use it to prove that your endpoint is reachable, answers quickly and verifies the signature before any real job exists. The dummy body says Sume webhook test. Not a job or Format run., and it is not appended to Requests, so nothing in your job history changes. Because it has no job_id, it cannot exercise your dedupe or your handler for a real result.

When should I use Redeliver?

Use it after a real delivery failed or your receiver was down. Sume re-POSTs that job's real terminal event (job.completed, job.failed or job.canceled). It still works after the automatic attempts are exhausted, because a manual redeliver does not consume one of the automatic 10.

For a Format run, the endpoint re-POSTs the current format.run.terminal receipt and signs it with the same secret, so the fingerprint header is unchanged and your verifier needs no change.

What errors and limits should I expect?

Redeliver never changes the destination: a new URL is a new job. A Format run redeliver returns 409 webhook_not_configured if the run had no webhook_url, and 409 run_not_terminal if it is still running. Treat job_id as the idempotency key on jobs, and request_id or run_id on runs, so a redelivered event is not processed twice.

Delivery is an optimization, not the only recovery path: keep status_url polling available for events that never arrive.

How many automatic attempts come before a manual one?

A job delivery gets up to 10 attempts in total, spaced by a fixed delay (30 seconds by default) rather than exponential backoff, with a 10-second timeout per attempt. A slow endpoint burns that budget and is retried. Run webhooks use the same 10-attempt cap on a different schedule, and the run webhooks page is authoritative for *.run.terminal deliveries.

Delivery status, including the attempt count, is visible on the job object and in job events when available, so check there before deciding to redeliver.

What is a sensible order to try them?

Send test first, to a URL you type, until the endpoint answers 2xx and verifies the signature. Then let a real job deliver. If that delivery ends up failed, fix the cause and use Redeliver on that job or run instead of resubmitting paid work.