OpenAI is shutting down the Sora 2 API. The scheduled removal date is September 24, 2026, covering both the Sora 2 models and the Videos API itself. OpenAI notified developers on March 24, and its deprecation table lists no recommended replacement. This is a confirmed retirement, even though the models and endpoints still have documentation. OpenAI deprecation notice.
As of September 5, the practical question is how to finish or replace your existing workflow before that date. First identify who serves your requests, then save any videos you can still retrieve, and validate a replacement through file delivery. A successful request alone is insufficient to establish that the migration works.
Which shutdown date applies to you?
The Sora app, OpenAI's direct API, and Microsoft Foundry have separate retirement schedules. Check your application's API base URL and deployment configuration before putting a date on your migration calendar.
| Where you use Sora | Applicable date | What to check |
|---|---|---|
| Sora website or mobile app | Discontinued April 26, 2026 | Whether your account still offers an export of existing work |
| OpenAI's direct Videos API | Removal scheduled September 24, 2026 | Every integration using the Videos API or a listed Sora 2 model |
Microsoft Foundry, sora-2 version 2025-12-08 | Retirement listed as October 15, 2026 | Your deployed version and Microsoft's notices for that deployment |
Microsoft Foundry, sora-2 version 2025-10-06 | Retirement listed as July 15, 2026 | Whether an old configuration still refers to this retired version |
The app and direct API dates come from OpenAI's discontinuation guidance. The Foundry dates come from Microsoft's current English retirement table, which lists the December version as Preview. Some older search snippets show September 15 for that version; the current English table checked on September 5 shows October 15. Microsoft's schedule does not extend access through OpenAI's own API.
For the direct API, the removal notice explicitly includes:
sora-2sora-2-prosora-2-2025-10-06sora-2-2025-12-08sora-2-pro-2025-10-06- The Videos API
Pinning a dated snapshot therefore does not avoid the shutdown. Neither does retaining an old SDK: the scheduled removal concerns the service it calls. The official notice does not specify a cutoff hour, timezone, or universal HTTP error after removal. Set your own earlier completion deadline instead of designing around an assumed midnight cutoff or 410 Gone response.
If your requests go through an intermediary, ask which upstream service and model version serve them and what the provider plans to do at retirement. A familiar model name in a dashboard does not establish continued upstream availability.
Save files, not just job IDs
Start with the videos you already have. Make an inventory containing the provider, model or deployment, job ID, last known status, business record it belongs to, and location of any downloaded file. Separate completed jobs without a saved file from unfinished jobs; they need different handling.
OpenAI documents an asynchronous lifecycle: a creation request returns a job, GET /v1/videos/{video_id} retrieves its status, and a completed job's video can be downloaded with GET /v1/videos/{video_id}/content. The documented states are queued, in_progress, completed, and failed; completion or failure can also arrive through video.completed and video.failed webhooks. Use your known job IDs and, where accessible, the paginated GET /v1/videos listing to reconcile your inventory. Videos API guide.
For each completed job, download any still-retrievable MP4 into storage you control. Check that it is nonempty and plays, then verify the duration and any audio your application expects. Keep the provider job ID alongside the saved file so you can connect a customer request, generated asset, and billing record later. Optional thumbnail and spritesheet downloads may matter if your product uses them, but neither substitutes for the video.
Do not treat the shutdown date as the retention period for every generated video. OpenAI's guide says ordinary download URLs are valid for a maximum of one hour after generation. It separately says Batch videos are available for up to 24 hours after batch completion. These are different windows, and neither promises that an older job can be recovered today. Retrieve video results.
For unfinished work, retrieve the latest status before deciding what to do next. If a submission timed out but you have a job ID, resolve that job before creating another. Blindly resubmitting can produce duplicate work and charges. Where a timeout leaves no known ID, treat the outcome as uncertain and reconcile the provider's records before an automatic retry. This is an application design precaution, rather than a promise that every provider supports deduplication.
A useful preservation check is to open a saved video from your own storage without following the provider's download URL. If that works and the file is connected to the right business record, you have preserved a usable result. A completed status, an expiring link, or a database row alone does not meet that test.
If your videos were created in the Sora app
OpenAI directs app users to the Sora export page, where the documented action is Export; an email arrives when the export is ready. Check whether that option remains available to your account. OpenAI says any final export window, if offered, will be announced by email, and describes deletion after discontinuation and any final export period. It does not give a universal future recovery deadline. Sora discontinuation and export guidance.
That account export process is separate from downloading Videos API results. Do not assume it will recover API jobs missing from your own storage.
Choose a replacement around the work your product must finish
OpenAI's retirement table leaves the recommended replacement blank. There is no official drop-in successor listed there. Build a short requirements list from your actual feature: text or image input, required duration and aspect ratio, audio, reference images, first or last frame control, extension of an existing clip, and how the result reaches a user. Those requirements determine which candidates deserve an integration test.
Google's current video documentation recommends Gemini Omni Flash for general video generation and conversational editing, and Veo 3.1 for scene extension, last-frame control, or legacy pipelines. That is Google's positioning, not a measured quality ranking. Confirm current access and the capabilities your workload needs before committing to either. Google video overview.
The integration differences are material. Gemini Omni Flash uses the Interactions API. Veo 3.1 uses asynchronous operations: its official SDK flow calls client.models.generate_videos, checks progress with client.operations.get, and downloads through client.files.download. Veo also documents native audio, first/last-frame control, and image references. Veo 3.1 documentation. Replacing sora-2 with another model string in an OpenAI Videos request does not implement these workflows.
Keep your application's business request ID separate from the provider's job or operation ID. Store both, along with the selected provider and the final file location. This lets your application track old Sora jobs while new requests use a different service, without pretending their status values, identifiers, or download behavior are interchangeable.
What counts as a finished migration?
Use a representative request from your own product and follow it all the way to the user's usable file. These are engineering acceptance criteria, not provider performance guarantees:
| Check | What you should be able to demonstrate |
|---|---|
| Submission | A valid request creates a recorded job or operation connected to the correct user request |
| Completion | Polling or webhooks reach a terminal state; the application handles failures and has a bounded waiting policy |
| Download | The application retrieves playable bytes and handles the provider's actual download lifetime |
| Required output | Duration, dimensions, audio, and any required frame or reference behavior satisfy the feature |
| Persistence | The saved file remains usable from your storage after the provider link expires |
| Recovery and billing | Timeouts, duplicate notifications, failed jobs, and retries can be reconciled without silently creating duplicate work |
Include failure handling in the change before sending normal traffic to the replacement. A webhook may arrive more than once; a polling timeout may occur before a provider job has finished. Your application needs to distinguish “we stopped waiting” from “the provider failed” and preserve enough information to reconcile late results.
Set a date to stop accepting new Sora work, leaving time to finish and download outstanding jobs before the applicable retirement. Switch new submissions only after the replacement meets your acceptance criteria. Continue tracking known Sora jobs separately until each has a saved result or an explicit failure outcome.
If no candidate meets a requirement your users depend on, retire or temporarily disable that feature with a clear explanation. Quietly substituting a model that cannot deliver required audio or frame control creates a different product behavior, even when the request succeeds. The migration is complete when your users receive the intended result and your team can account for the outstanding work—not when the configuration file contains a new model name.
