Format run webhook redeliver 409: not configured or not terminal

A 409 from POST /v1/format-runs/{run_id}/webhook/redeliver means the run cannot be replayed yet, and the error code tells you why. webhook_not_configured means the run was created without a webhook_url, so there is no destination to replay to. run_not_terminal means the run is still going and there is no terminal receipt to send. Neither is a delivery failure, and neither is fixed by retrying the same call.

This page covers Format runs. The details come from Runs and results, Run webhooks and Errors and spend. Generation-job redeliver is a different route and is covered at the end.

What does the redeliver call actually do?

Redeliver re-POSTs the run's current format.run.terminal receipt to the URL stored on the run, with a fresh timestamp and a fresh signature. It needs a key with formats:write and an empty body. It is signed with the same secret as the original delivery, so x-sume-webhook-secret-fingerprint is the same twelve characters and your verifier needs no change.

It still works after the automatic attempts are exhausted, and it does not consume one of the automatic ten. It never sends to a different URL: the destination was fixed when the run was created.

Which 409 do I have, and how do I fix it?

Both codes come back in the standard error envelope, so branch on error.code rather than the message.

Why does insufficient scope say 403, not 404?

Docs state that missing formats:write is always 403 insufficient_scope, never 404. A run you cannot see is 404 format_run_not_found. That split matters when you debug: a 404 means check the key and run id, a 403 means the key is fine but too narrow. Reads need formats:read, while cancel and redeliver need formats:write, so a read-only monitoring key can poll a run but cannot replay its webhook.

How do I replay safely from a script?

Check the run first. If status is not terminal, do not call redeliver at all. If webhook_delivery is null, the run has no URL. Otherwise, call redeliver and read the redelivery object in the response, which carries delivered, status_code and error for the POST you just triggered.

webhook_delivery describes the stored delivery row, not your replay. A failed redeliver of a call that had already been delivered keeps the row on the earlier 2xx and only counts the attempt in manual_redeliveries.

RUN=arun_e43e6c5cb2b74052
STATUS=$(curl -sS "https://api.sume.com/v1/format-runs/$RUN/status" \
  -H "Authorization: Bearer $SUME_API_KEY")
echo "$STATUS" | jq '.data.status'

# Only when terminal and the run had a webhook_url:
curl -sS -X POST "https://api.sume.com/v1/format-runs/$RUN/webhook/redeliver" \
  -H "Authorization: Bearer $SUME_API_KEY" | jq '.redelivery'

Is redeliver the same as Send test?

No. Send test, on /dashboard/webhooks or POST /v1/webhooks/test-deliveries, fires a dummy webhook.test payload to a URL you type. It is not a replay of a real run. Use it to prove your endpoint and signature check work before any run exists. Use redeliver once you have a real terminal run and want your handler to see the real receipt again.

Your handler should still dedupe on request_id, which equals run_id and repeats on every attempt. For ordering use created_at. Job webhooks use POST /v1/jobs/{job_id}/webhook/redeliver with jobs:write and key on job_id, as described in Webhooks.

What if my handler never fires after a successful redeliver?

The response to the redeliver call carries a redelivery object; read redelivery.delivered and redelivery.status_code to see what your endpoint said. If delivered is false, the URL is probably the problem. The destination is re-validated as public HTTPS at delivery time, redirects are not followed, and a 3xx is a failed attempt. Because redeliver cannot change the destination, a wrong URL means starting a new run with the right communication.webhook_url.

Also confirm the receiver verifies the new timestamp. Redeliver stamps the POST with the current time, so a receiver that compares against the original run time will reject a perfectly valid replay. The standard five-minute replay window applies to the fresh timestamp.