See every webhook attempt for a Sume video job: webhook.delivery

To see whether Sume reached your webhook for a finished render, read GET /v1/jobs/{id} for its webhook_delivery object and GET /v1/jobs/{id}/events for the webhook.delivery entries. The delivery status runs pending, delivering, delivered, retrying, failed, or exhausted.

That is the first thing to check when a 30-second render is completed and your system never heard about it. The job reached its real terminal state; only the delivery may have failed.

Where the delivery state lives

Sume documents that the webhook delivery status, with the attempt count, shows on the job object and in job events when it is available. The job object's webhook_delivery carries the url, a last_error, and a signing_secret_fingerprint. If another member's turn reads your job, url and last_error come back as null, so a teammate sees the state but not your endpoint.

The public event list for a job is job.created, job.queued, job.started, generation.submitted, job.completed, job.failed, job.canceled, and webhook.delivery. Public events never show raw provider task ids or raw provider URLs (Jobs and results).

Reading the values

A one-line check

The docs name the webhook.delivery event but do not publish its field layout, so this filter matches the name under either a type or an event key instead of guessing. Set SUME_JOB_ID first.

curl -fsS "https://api.sume.com/v1/jobs/$SUME_JOB_ID/events" \
  -H "Authorization: Bearer $SUME_API_KEY" |
  jq '[.. | objects
       | select(.type? == "webhook.delivery" or .event? == "webhook.delivery")]'

curl -fsS "https://api.sume.com/v1/jobs/$SUME_JOB_ID" \
  -H "Authorization: Bearer $SUME_API_KEY" |
  jq '.. | objects | select(has("webhook_delivery")) | .webhook_delivery'

What to do next

• delivered but your system disagrees: your handler returned 2xx before it stored the event. Store first, then answer.
• retrying or exhausted: look at last_error, fix the endpoint, then call POST /v1/jobs/{job_id}/webhook/redeliver with a key that has jobs:write. It sends the real terminal event with a fresh timestamp and signature and does not use one of the ten automatic attempts.
• Signature failures: compare x-sume-webhook-secret-fingerprint with the fingerprint next to your secret in the dashboard before you open a ticket.

Delivery is not recovery

Sume tries up to 10 times, 30 seconds apart, with a 10-second timeout each. After that you have a failed delivery and a job that still finished. For a clip that cost $3.75 at 720p on Wan 3.0 or $17.34 on Seedance 2.5, do not render it again; read the status and result by job id.

Reading it in a script

A script that runs after an alert should do three things in order. First, fetch the job status and stop if it is not completed, because a webhook for a job that never finished is a different problem. Second, fetch the delivery state and print the status and last_error. Third, decide: if the status is retrying, wait for the next automatic attempt; if it is exhausted, fix the endpoint and call redeliver.

Keep the output short enough to paste into a chat. The attempt count, the last error and the fingerprint are usually enough for a teammate to see whether the receiver, the secret or the network is at fault.

One more habit helps with 30-second renders in particular: log the job id at submit time, next to the model, resolution and seconds. When a long job completes at an odd hour and the delivery trail is all you have, that id is the only thing that connects your database to Sume's events.