x-fal-no-retry header: safe retries with a Sume Idempotency-Key

fal retries failed queue requests automatically and lets you disable that per request with the X-Fal-No-Retry header. Sume's approach for a paid submit is different: retry freely, but send an Idempotency-Key so the retry returns the original job and cannot bill twice.

fal details are from its Reliability page; Sume details from Generation admission, Errors and credits and Jobs and results, read 2026-10-01.

What does fal retry on its own?

The fal page says that with the queue, it automatically retries requests that fail with 503, 504, connection errors, or 429 from exceeding the concurrent request limit. Requests are retried up to 10 times with backoff. It also says failed requests returning 5xx are not billed, that retries apply only to queue-based requests, and that the Queue page covers disabling retries with X-Fal-No-Retry.

What does Sume say about retrying a submit?

The errors page says to back off on 429, use retry-after when present, and not to retry unsafe submit requests without an Idempotency-Key. The admission page adds: use Idempotency-Key for every paid submit that may be retried. Retrying the submit is fine when you reuse the same key, because the retry returns the original job instead of billing a second one.

What happens if I reuse a key wrongly?

Reusing a key for a different operation or payload returns 409 idempotency_conflict. The documented action is to reuse keys only for exact retries. Generate one key per intended generation, store it with your own record of the request, and send the identical body each time.

Should I retry after my own timeout?

Do not submit a new paid job just because your local worker timed out. If the sync wait ran out, continue with GET status_url. If you do not know whether the submit arrived, retrying with the same key either returns the original job or creates the one you intended. See idempotency keys for AI video APIs.