# How Do You Save AI-Generated Videos Before Temporary Download Links Expire? > Save generated videos by treating provider URLs as short-lived transfer credentials, not asset locations. Queue a download as soon as a job completes, stream it into durable object storage, verify size, type, and checksum, and record the permanent URI before marking the production job complete. # How Do You Save AI-Generated Videos Before Temporary Download Links Expire? A completed generation is not a durable asset until the bytes exist in storage you control. Many video APIs return a signed or temporary download URL designed for transfer, not long-term playback. Saving only that URL can make an approved video disappear from your application hours or days later. Build a separate ingestion step that begins when generation completes. It claims a download task, obtains a current URL, streams the media to a temporary object, validates it, and promotes it to a deterministic permanent key. Only then should the production job become complete. ## Treat the URL as a credential A signed URL often grants temporary access to an object without another authorization header. That makes it sensitive. Do not expose it in analytics, customer-visible logs, tickets, or permanent database fields unless access is tightly controlled. Store instead: * the provider job ID; * the provider output identifier when available; * URL issue and observed expiration times; * download attempt records; * the final object-storage key; * verification metadata and checksum. If the provider returns an explicit expiration time, schedule the first download well before it. If no lifetime is published, assume the link is ephemeral and enqueue the transfer immediately. ## Separate generation from asset ingestion Generation completion and durable saving are different states. A job can succeed remotely while your download fails locally. | State | Meaning | Next action | |---|---|---| | `generating` | Provider is creating the video | Poll or await webhook | | `output_ready` | Provider reports a completed output | Enqueue download | | `downloading` | Worker owns a transfer attempt | Stream to temporary storage | | `verifying` | Bytes arrived | Inspect and checksum | | `stored` | Durable object is confirmed | Save permanent URI | | `complete` | Metadata and asset are committed | Deliver to consumer | | `download_retry` | Transfer failed transiently | Refresh URL and retry | | `needs_attention` | Output cannot be recovered automatically | Escalate with evidence | Do not mark the job complete at `output_ready`. That shortcut is the main reason systems later discover that their database points to expired links. ## Acknowledge webhooks before downloading Webhook handlers should validate the event, persist it, enqueue the output, and respond quickly. Downloading a large video inside the webhook request risks a timeout and repeated delivery from the provider. Deduplicate events by event ID or by a combination of provider job ID and output ID. Make the enqueue operation idempotent with a unique key such as: ```text download_key = provider + provider_job_id + output_id ``` Repeated webhooks then converge on one download task. Polling and webhooks can both call the same idempotent `ensure_download_task` operation. ## Stream into a temporary object Avoid reading the full response into application memory. Stream chunks to a temporary file or multipart object upload while calculating a cryptographic checksum. A safe transfer sequence is: 1. Claim the download task with an expiring lease. 2. Obtain a fresh URL if the API supports refreshing it. 3. Send the request with bounded connection and read timeouts. 4. Reject redirects to unexpected hosts according to policy. 5. Stream chunks while counting bytes and computing SHA-256. 6. Close and finalize the temporary object. 7. Validate the media. 8. Promote or copy it to the final key. 9. Commit the durable URI and metadata. Use backpressure so the worker does not buffer faster than storage accepts data. Limit concurrent transfers by bandwidth, file size, and storage service capacity rather than only by job count. ## Validate bytes, not response headers alone An HTTP `200` can contain an HTML error page, JSON message, or truncated file. `Content-Type: video/mp4` is useful evidence but not proof. | Validation | Failure caught | |---|---| | Nonzero byte count | Empty response | | Expected or plausible length | Truncated transfer | | File signature | HTML or JSON saved as video | | Container parse | Corrupt media structure | | Duration greater than zero | Invalid or incomplete video | | Dimensions and codec | Output outside delivery contract | | SHA-256 checksum | Changed or duplicate bytes | | Decode sample when warranted | Media that parses but cannot play | Store observed metadata beside the object. Compare it with requested duration and resolution using tolerances appropriate for the model and container. Do not reject a valid video merely because container duration differs by a few frames unless the delivery contract requires exact timing. ## Use deterministic durable keys A predictable key makes retries idempotent and assets traceable. Include stable business identity, output variant, and a version or checksum. ```text videos/{account}/{operation_id}/{attempt_id}/{output_id}-{sha256_prefix}.mp4 ``` Write first to a temporary namespace. After validation, promote the object or commit a database pointer to the verified checksum-addressed key. If another worker already stored the same checksum for the same task, reuse it rather than create an unrelated duplicate. Keep user-supplied filenames out of raw storage paths unless they are sanitized. Store the original display name as metadata. ## Recover from expiration and interrupted transfers Classify errors so retries are purposeful. * Connection resets and temporary storage errors can usually retry with backoff. * An authorization or expiration response may require a refreshed URL. * A not-found response may mean the provider already removed the asset. * Repeated checksum or media-validation failure should stop automatic retries. * A local quota or permission failure requires operational action, not another provider call. Preserve the provider job ID. Many APIs can return a new signed URL for an existing completed job even after the first URL expires. Verify that behavior for the current endpoint instead of assuming it. Resume partial downloads only when both the origin and destination support verified byte ranges and the object's identity has not changed. Otherwise restart the transfer into a new temporary object. Combining bytes from two versions can produce a file that looks complete but is corrupt. ## Choose a retry schedule that respects expiry Ordinary exponential backoff may wait beyond the remaining URL lifetime. Use the known expiration to bound delay. ```text next_delay = min(exponential_backoff, time_until_expiry - safety_margin) ``` If the URL is already near expiry, refresh it before retrying. Apply random jitter so a provider recovery does not cause every failed worker to reconnect simultaneously. Set separate limits for transfer attempts and URL-refresh attempts. A task that repeatedly receives an invalid file should not consume unlimited fresh URLs. ## Secure the storage path The permanent object should follow your own access policy. Use private buckets by default, server-side encryption where appropriate, narrowly scoped worker credentials, and short-lived delivery URLs for viewers. Do not copy source URL query strings into metadata. They may contain signatures. Redact URLs in logs or store only the host, path hash, issuance time, and expiration time. Apply malware scanning or content moderation when required by the product. Keep tenant boundaries in object keys and authorization checks, but do not rely on path names alone for access control. ## Create retention and derivative policies Durable does not mean permanent. Define lifecycle rules for originals, approved masters, previews, and rejected attempts. | Asset class | Example policy consideration | |---|---| | Approved master | Customer contract and regeneration cost | | Delivery derivative | Can be recreated from the master | | Rejected generation | Short audit or dispute window | | Temporary upload | Delete automatically after verification window | | Review proxy | Retain through approval, then expire | Record deletion state and reason. If an asset must remain reproducible, preserve the prompt, source hashes, model ID, parameters, and rights to source materials, while recognizing that nondeterministic generation may not recreate identical bytes. ## Monitor the time-to-durability Measure the interval from provider completion to verified storage. This is the risk window during which a temporary link is your only copy. Useful metrics include: * outputs waiting for download; * oldest output-ready age; * completion-to-storage percentile; * URL-expired responses; * transfer retries and refreshed URLs; * checksum or media-validation failures; * bytes downloaded and stored; * jobs marked complete without a durable URI. The last metric should be zero. Alert before backlog age approaches the shortest observed URL lifetime. ## Keep model access and storage responsibilities clear [Atlas Cloud](https://www.atlascloud.ai/?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=save-ai-videos-before-download-links-expire) can provide one OpenAI-compatible platform for text, image, and video model access. A unified platform can simplify job metadata and billing, but your application remains responsible for copying outputs into storage that meets its retention and delivery requirements. Verify the exact output and refresh behavior of the current model endpoint. Do not invent an expiration duration or assume every model exposes the same download mechanism. Build the ingestion adapter so those differences are configuration and capability checks rather than scattered assumptions. ## The bottom line Save AI-generated videos by treating temporary URLs as expiring transfer credentials. Enqueue the download immediately after generation, stream into a temporary object, validate the actual media, and promote it to a deterministic durable key. Record the permanent URI and checksum before declaring the job complete, and design URL refresh, retries, retention, and monitoring so a provider link can expire without taking your only copy with it. ## FAQ ### Can I store the provider's download URL as the final video location? No. Signed or temporary URLs can expire, be revoked, or change. Store the durable object key and provider job ID, and request or use a fresh transfer URL only when needed. ### Should the download worker load the entire video into memory? Usually not. Stream the response to a temporary file or multipart object upload while computing a checksum so large files do not exhaust memory. ### What should be verified before a video is marked saved? Verify the HTTP response, content length when available, file signature, expected container, nonzero duration, dimensions or codec requirements, checksum, and successful durable-storage write. ### What happens if the temporary URL expires during a download? Keep the production job and remote job ID, discard or quarantine the incomplete object, request a fresh URL if the API supports it, and resume or restart according to verified range support. ### How long should original generated videos be retained? Set retention by customer needs, legal and privacy requirements, regeneration cost, and storage budget. Use lifecycle policies rather than accidental dependence on provider URLs. ### Can a webhook download the video directly? The webhook handler should acknowledge quickly and enqueue a download task. A separate worker can retry safely, verify the asset, and avoid losing events to long network transfers.