Runway ASSET.INVALID vs Sume validation and unreachable media
Runway's ASSET.INVALID covers any unacceptable input media. Sume separates validation errors from fetch failures, and one 502 is still your input to fix.
Runway's ASSET.INVALID means an input image or video is not acceptable for the task, often its dimensions, duration or other properties, and you should not retry. Sume splits the same situation in two: a validation category ("Fix input") for a bad request, and separate codes such as input_media_unreachable when Sume could not fetch the media. A validation failure needs a fixed request; an unreachable-media failure needs a reachable URL first.
Runway text is from its Dev docs; Sume text from Errors and rate limits. Both read 2026-10-01.
How does Sume classify bad input media?
There are three places it shows up, and the next step differs a little.
| Code or category | Meaning | Next step |
|---|---|---|
validation (job category) | The request or its values are not valid | Fix input |
image_not_fetchable / input_media_unreachable | Sume could not fetch or mirror media safely (503 class) | Check the media is a public HTTPS image URL, then retry or contact support with the request id |
attachment_fetch_failed (502, Formats) | Sume could not fetch an attachment | next_action is fix_input: make the URL publicly reachable |
Why is a 502 still my problem?
The Formats errors page says it directly: despite the 5xx, an attachment_fetch_failed is your input, and next_action is fix_input. If you only look at the status class, you would retry it as a server fault. Read next_action first. More on the URL rules in HeyGen download failed versus Sume.
Which media limits can I check before submitting?
Some are written down. For the legacy Video 1.0 endpoint documented in Video 1.0, reference_video_urls takes 1 to 3 video URLs, reference_image_urls takes 1 to 9 images, and reference_audio_urls takes 1 to 3 audio URLs and needs at least one reference image or video. Runway's page gives no numbers for its own limit, so compare against each provider's reference, not this table.
Should I ever retry after a fetch failure?
Once, after you have confirmed the URL opens in a private browser window with no login. If the same code returns, send the request_id (also the x-sume-request-id header) to support. Do not include signed URLs or keys.
Sources
Related posts
More in Developers
- Runway failureCode is diagnostic: what to show users from Sume
Runway says not to show SAFETY failure codes to users. On Sume, show your own text keyed on code; keep message, request_id and details in logs.
- gen3a_turbo no longer available on Runway: re-read Sume's model list
Runway now fails requests for gen3a_turbo and gen4_aleph. Avoid the same break on Sume: read /v1/videos/models instead of hard-coding ids.
- Runway INTERNAL.BAD_OUTPUT.01: fix the prompt, then resubmit
Runway's INTERNAL.BAD_OUTPUT.01 may succeed after prompt fixes. Sume's equivalent step: inspect job events, fix the input, and send a new request.
- Runway INTERNAL or null failureCode: how long to delay a retry
Runway says to add a delay for INTERNAL or null failure codes but gives no number. Sume's errors carry retryable and retry_after_seconds fields.
Written by Sume