Sume Send test vs Redeliver: which to use for avatar video jobs

Use Send test to prove your endpoint and secret work before any real job exists, and Redeliver to replay the real terminal event of a specific job after your receiver was down. Send test never replays a job; Redeliver never sends a dummy.

Both are described in Webhooks, read 2026-10-10.

The difference

A first-time setup

Before you wire avatar videos in, send a test to your staging URL. A pass proves the URL is reachable, the raw body reaches your verifier unmodified, and the signing secret is right. If verification fails, compare the x-sume-webhook-secret-fingerprint header with the fingerprint shown next to the secret in the dashboard; neither side has to send the secret.

Then create one short avatar video with webhook_url and mode: webhook, and watch the real event arrive.

After an outage

If your receiver returned errors during a deploy and Sume used its attempts, the job is still complete: the result is available at its result URL. Redeliver pushes the terminal event again, so your pipeline moves on without a manual lookup.

Treat job_id as the idempotency key on your side. A redelivery is the same job, so a handler that inserts by job_id and ignores duplicates stays correct.

Limits worth remembering

Redeliver does not change the destination: a new URL means a new job. And a webhook is an optimization, not the only recovery path, so keep the status URL poll available for events that never arrive.

A short checklist

Before go-live: send a test, confirm the verifier returns true for it, and confirm it returns false when you alter one byte of the body. Then run a real short avatar job end to end. After go-live: log the delivery id and job_id for every event, alert on a gap between a job's creation and its terminal event, and use Redeliver, not a new job, to recover a missed event.

Keep Send test away from production data flows. Because it never carries a job_id, a receiver that tries to look one up should treat it as a harmless no-op.

Common mistakes

Teams often use Send test to look for a real job's payload and conclude that the integration is broken because there is no job_id. The test body is deliberately generic. Another common mistake is creating a new job to recover a missed event: that costs a second render, when Redeliver would have re-sent the first at no extra generation cost.

A third is verifying the signature against a parsed and re-serialized body. Both Send test and real deliveries are signed over the raw bytes, so use the raw body in the verifier.

Permissions

The two actions use different scopes. Send test through the API needs account:write, and Redeliver needs jobs:write. A key made for a render worker usually has the second but not the first, so a failing test call from that key is a scope error, not a broken endpoint. Use a dashboard session for tests, and keep the render key narrow.

Where each action leaves a trace

A redelivery shows up as a new delivery row for the same job, while a test does not appear in Requests at all. When you audit an integration, expect the first to add rows for a known job_id and the second to add none.