# What Happens to Input Files and Output URLs When Migrating a Sora App? > Provider file references and generated-video links are not portable assets. Retain original input bytes under application asset IDs, upload them in the target format, map source and target jobs separately, and copy completed videos into durable storage before provider resources expire. When migrating a Sora app, input references usually need to be uploaded or reformatted for the target provider, while generated video URLs should be treated as temporary download locations. Move both sides behind an asset layer that owns durable files, checksums, access policy, and provider mappings. An API-compatible request shape does not make file IDs or output links portable. Those resources normally belong to the provider that issued them. ## Separate assets from provider references Use an application asset ID as the stable key: ```json { "asset_id": "asset_01J...", "kind": "input_image", "sha256": "...", "storage_key": "inputs/asset_01J...png", "provider_refs": { "openai": "provider-specific-reference" } } ``` The source file ID, video job ID, and signed output URL are attributes of that record, not identifiers exposed as your product's permanent contract. ## Rehydrate input references OpenAI's video endpoint accepts a prompt and can accept an optional `input_reference` image. A target service may require multipart upload, a pre-uploaded file ID, a public URL, or base64 data. For each source input, read the durable original from your storage, validate its media type and dimensions, then create the target-specific reference. Do not assume an OpenAI file or media identifier can be submitted to another vendor. If your application stored only a provider reference and no original, verify whether it can still be downloaded before migration. Expired or deleted inputs require user re-upload; there is no safe identifier conversion that recreates missing bytes. ## Map job objects explicitly Sora video generation is asynchronous. The job has an ID, status, progress, model, duration, size, timestamps, and possibly an expiration time for downloadable assets. Store the target job beside the source job: | Application field | Source mapping | Target mapping | |---|---|---| | Internal job ID | Your database | Same value | | Provider job ID | OpenAI video ID | Target job ID | | State | Source status | Normalized target status | | Input asset | Source reference | Re-uploaded target reference | | Output asset | Downloaded bytes | Downloaded target bytes | Never overwrite the source mapping during a staged migration. Keeping both makes rollback and support investigations possible. ## Download output content, not just the URL The OpenAI API exposes a content endpoint for a completed video job and reports `expires_at` when assets have an expiration. A URL copied from a response may stop working, require authentication, or be unsuitable for direct client exposure. On completion, your worker should: 1. retrieve the video content from the authenticated endpoint; 2. stream it into application-controlled object storage; 3. verify media type, file size, and checksum; 4. record provenance, model, prompt policy, and generation parameters; 5. serve it through your own authorized delivery URL. Apply the same process to thumbnails, previews, or other downloadable variants that the product relies on. ## Plan for retention and privacy Copying files changes data governance. Define retention separately for user uploads, generation intermediates, final videos, thumbnails, and failed jobs. Encrypt stored assets, restrict service roles, and avoid logging signed URLs or raw prompts. When deletion is requested, remove the application copy and call provider deletion endpoints when available. Keep a deletion tombstone with non-sensitive identifiers so retries remain idempotent. ## Test media behavior before cutover Build fixtures for every accepted input format, orientation, resolution, duration, and maximum size. Verify alpha channels and color profiles if image references matter. For outputs, test expired links, partial downloads, content-type mismatches, range requests, cancellation, and retry after a worker crash. Compare generated media policy and moderation outcomes as well as API mechanics. A request that is syntactically accepted by both providers may still differ in allowed content or result characteristics. ## The bottom line Sora file references and output URLs are provider resources, not portable assets. Preserve original input bytes in your own storage, create new target references, download completed videos promptly, and expose stable application asset IDs. That makes the migration reversible and prevents expiring links from becoming data loss. ## FAQ ### Can an OpenAI input_reference be sent to another video provider? Usually not. Read the original file from your storage and create the target provider's required multipart upload, file ID, URL, or base64 reference. ### Are Sora output URLs permanent? Treat them as temporary or authenticated delivery locations. The video job can include an expiration time, so download content promptly into storage you control. ### What if I kept only a provider file ID? Try to retrieve the original bytes while the provider resource is available. If it has expired or been deleted, the user may need to upload the source again. ### Which ID should the application expose? Expose your own stable asset and job IDs. Keep source and target provider IDs as mappings for retrieval, support, and rollback. ### Should source mappings be overwritten after cutover? No. Retain source and target mappings during the staged migration so you can compare behavior and roll back safely. ### What must be tested for video assets? Test every supported format, size, duration, orientation, download variant, expiration path, partial transfer, cancellation, and storage retry.