Runway task failure codes: which to retry, which not to
Runway says never retry SAFETY or ASSET.INVALID failures, retry INTERNAL ones with a delay. The same triage on Sume: 429 with retry-after, new keys for runs.

Runway's task-failure guidance splits by failureCode: do not retry SAFETY and ASSET.INVALID failures, and retry INTERNAL ones only after a delay. The same discipline works on Sume: back off on 429 using retry-after, and retry a failed Format run with a new Idempotency-Key.
Runway facts are from its Dev docs, read 2026-10-01. Sume facts are from Errors and credits and Format run errors.
Which Runway failure codes should I not retry?
SAFETY.INPUT.* and SAFETY.OUTPUT.* mean content moderation rejected an input or the output; the docs say not to retry. They also warn the third part of the code is diagnostic only and may not match the input (a SAFETY.INPUT.TEXT can occur with no prompt text), so do not show it to end users as fact. INPUT_PREPROCESSING.SAFETY.TEXT and ASSET.INVALID are also no-retry: the first is a rejected prompt, the second a problem with the dimensions, duration or other properties of the media you sent.
| failureCode | Retry? |
|---|---|
SAFETY.* | No |
INPUT_PREPROCESSING.SAFETY.TEXT | No |
ASSET.INVALID | No, fix the input |
INTERNAL.BAD_OUTPUT.* | May retry, after correcting the prompt |
INPUT_PREPROCESSING.INTERNAL | May retry, with a delay |
THIRD_PARTY.UNAVAILABLE | Not immediately; wait, then may retry |
INTERNAL or null | May retry, with a delay |
What does retry-with-delay mean in practice?
For HTTP errors, Runway's docs say 429, 502, 503 and 504 may be retried, using exponential backoff plus jitter of up to 50% of the delay. Its SDKs retry automatically. A task that finishes as failed is a different layer from a request that errors, so apply the per-code table above to failureCode and the backoff rule to HTTP status.
How does Sume's retry rule compare in shape?
Sume's docs say to back off when you receive 429, use retry-after when present, and not to retry unsafe submit requests without an Idempotency-Key. For Format runs, the error page says to retry a failed run with a new Idempotency-Key, because the old one is bound to the receipt you already have; and that the error set is open, so handle known codes and fall through on the rest. See Retry-After on 429 and idempotency keys.
What should my retry code branch on?
Branch first on whether the cause is your input (fix it, do not loop) or a transient condition (wait, then retry once or twice). Cap attempts, log the code, and never retry a request that could bill again without a key that makes the repeat safe.
Sources
Related posts
More in Developers
- Synthesia Billing API credit usage vs Sume's /v1/usage ledger
Synthesia added a Billing API endpoint for credit usage. Sume's equivalent is GET /v1/usage: reservations, captures and refunds, filterable by run or job.
- TikTok photo post API: 35 image URLs, PULL_FROM_URL, cover index
TikTok's photo post endpoint takes up to 35 public image URLs by PULL_FROM_URL and a photo_cover_index. How to plan the generated-image batches that feed it.
- TikTok photo post API: is_aigc label and auto_add_music
Set is_aigc to true on a TikTok photo post of generated images to add the AI-generated tag. auto_add_music is direct post only. And the audit rule.
- TikTok photo post title length: 90 runes, description 4000
TikTok's photo post API caps the title at 90 UTF-16 runes and the description at 4000, unlike video posts. How to count them and where Sume fits in.
Written by Sume