storage_expired — files deleted by retention

POST /storage/url for a path from result.files[] returns 404 {"success": false, "message": "File not found."}. Under the same name, the code also appears as a field in the chunk preview response — next to the chunks_purged value, which means only the fragments were deleted and the result is still there.

Order storage is deleted by retention: by default 7 days after the order reaches a terminal status (completed, result_delivered, failed, compensated, cancelled). The order record itself remains in the database — only the files disappear.

The main trap: after retention expires, GET /orders/{order} STILL shows the old paths in result.files[]. The user-facing response has no separate expiry flag — a "dead" path can be told apart from a live one only by the 404 when you request a link. The files cannot be restored: they no longer exist. The right habit is to download the result as soon as the order is completed, without delay; subtitles are stored separately, in result.service_files[], and are deleted along with everything else.

POST /orders/{order}/retry creates a NEW order with the same parameters and is billed again. This is the only way to get the file again.

• Guide: files and storage
• POST /storage/url
• GET /orders/{order}
• POST /orders/{order}/retry
• 404 — resource not found