Five Sume video submit errors and which ones to retry

A video submit that does not come back 202 fails in one of five documented ways on Sume, and only three of them are worth retrying. 402 insufficient_credits means the balance cannot cover the reservation: raise the balance or choose a cheaper request. 409 idempotency_conflict means you reused a key for a different payload: never retry with that key. 429 queue_full, 429 rate_limited and 503 provider_capacity_exceeded are the retryable ones, each with its own wait.

The table below is the decision list from the admission and error pages, read on 2026-10-03. It is meant to be pasted into a retry wrapper as a switch statement.

The decision table

In every retryable case the guidance is the same: reuse the same Idempotency-Key, so the retry returns the original job and does not bill a second one.

Why queue_full is not rate_limited

The two share a status code and mean different things. rate_limited is about request volume. queue_full is about accepted work: Sume admits paid jobs as queued while queue capacity remains, so a full processing slot is not an error by itself. The error appears only when the queue is also full. Retrying faster does nothing for queue_full; finishing or cancelling jobs does.

The error details can include a generation_limits snapshot and job metadata for the failed admission attempt. Sume releases or refunds the reservation for a failed admission when applicable, so a queue_full rejection does not leave a charge behind.

A small retry switch

Treat 400, 401, 402, 404 and 409 as stop-and-fix. Treat 429 and 503 as wait-and-retry with the same key. Read the retry-after header before choosing a delay, and fall back to exponential backoff when it is absent. Count a retry budget per job, not per process, so a stuck workspace does not turn one failed clip into a thousand requests.

What the docs leave open

The docs do not publish a retry-after value for queue_full, and they do not give a numeric rate limit for submits. They describe queue capacity by plan, and tell you to prefer the effective values returned in generation_limits over any static table. Read those at runtime.

Putting it in code

A wrapper needs only a small function that returns one of three actions: stop, wait or retry. Return stop for 400, 401, 402, 404 and 409. Return wait for queue_full, with a poll of your own jobs. Return retry with backoff for rate_limited and provider_capacity_exceeded. Log the request_id in every case.

Keep the idempotency key in the same record as the clip it belongs to, not in memory. A process that restarts must find the same key for the same clip, or the retry is a new paid job.