Sume 429 rate_limited: honor retry-after and use an Idempotency-Key
On a Sume 429 rate_limited, back off using retry-after if present, and never retry an unsafe submit without an Idempotency-Key. Headers explained.

On 429 rate_limited, back off. If retry-after is present, use it. Do not retry unsafe submit requests without an Idempotency-Key (read 2026-10-06 in the errors docs).
Which headers can I read?
Responses can include ratelimit-limit, ratelimit-remaining, ratelimit-reset and retry-after.
import time
def wait_seconds(headers: dict, attempt: int) -> float:
if "retry-after" in headers:
return float(headers["retry-after"])
return min(60.0, 2.0 ** attempt)
print(wait_seconds({"retry-after": "7"}, 1), wait_seconds({}, 3))What should I do in practice?
queue_full is a different 429.
- Prefer
retry-afterover your own schedule. - Add jitter across workers.
- Keep one idempotency key per logical request.
Sources
Related posts
More in Developers
- A 5xx on a Sume paid submit never proves no job: retry with the key
On Sume, only a validation, authorization or balance error proves a paid create was refused. A 5xx does not, so retry with the same Idempotency-Key.
- sume/auto 400 unsupported_capability: 11 s, 2 s, 480p and silent audio
sume/auto fails closed on 2 s, 11 s, 480p, 768p and generate_audio false. The request is rejected before any provider call. Here is what to send instead.
- AI video client timeout: the Sume job still runs and still bills
A timeout on your HTTP client does not cancel a Sume job. Save the job id, poll the polling_url, and cancel only before generation starts. Python example.
- Sume mode webhook without a webhook_url: no delivery is armed
On a Sume Format run, communication.mode is descriptive; only a webhook_url arms delivery. Send the URL, then keep status_url as your backup.
Written by Sume