OpenAI schedules the retirement of the Sora API for September 24, 2026: what teams should review

The announced date and affected components

OpenAI’s deprecations documentation sets September 24, 2026, as the retirement date for the Videos API and the sora-2 and sora-2-pro models, as well as the snapshots listed on that page. Its replacement column does not list an alternative. Based on the official information provided, teams should therefore avoid planning on the assumption that there will be an automatic migration, an extension, or a compatible replacement model.

The date is a published schedule, not confirmation that the service has already been shut down or of exactly how it will behave at that point. The video-generation guide currently documents a workflow in which jobs are created asynchronously, their status is checked, and the resulting file is downloaded. The retrieval reference also describes job metadata, including the expires_at field for downloadable assets. None of these descriptions explains what will happen to requests, in-progress jobs, or metadata once the retirement date is reached.

The practical implication is to distinguish between two tasks: preparing for product continuity and preserving your own assets that are already available. Saving a downloaded video can preserve that file, but it does not, by itself, maintain the ability to generate other videos through the integration. Conversely, an application retaining a reference or job ID does not prove that the asset will remain retrievable.

Do not confuse the API with the app or website

The Videos API is an interface that lets applications and workflows perform video generation and retrieval operations through programmatic requests. The technical guide describes creating a job, checking its status, and downloading its content. This makes it possible to identify specific software dependencies: API calls, response processing, and components that expect to receive a video or query its metadata.

An API retirement should not automatically be described as the closure of an application or website for users. These are different channels and may have different schedules, terms, and export tools. However, the sources verified for this article document the API and do not establish when the Sora app and website closed—or whether they did. They also provide no export or deletion instructions for those products. For that reason, app export information cannot be used here to conclude what will happen to data or assets created through the API.

This distinction matters to teams that use more than one channel. A library of videos downloaded through the API, a user account in an app, and an API-connected production system may involve different assets and dependencies. Each channel requires its own official instructions to be checked; the available sources do not support treating these cases as subject to one unified retention policy.

What to review in an integration before the date

Start by finding every dependency, not just the point where a generation is requested. In the technical guide, the creation operation uses POST /videos; status checks use GET /videos/{video_id}; and the file is retrieved using GET /videos/{video_id}/content. These names are useful clues when searching code, configuration, logs, scheduled jobs, and third-party services that may hide the direct API call.

Next, document which parts of the product depend on each operation. For example, a request may trigger an editing process, wait for a job to finish, and then send the file to storage or review. If a call becomes unavailable, the failure could propagate to downstream components, although the documentation provided does not specify the response code or service behavior after shutdown. The appropriate response is to test error handling and design a controlled fallback, not to claim in advance how the provider will respond.

Teams should also distinguish assets already held in their own storage from assets that can only be retrieved through the API. For each downloaded video, they can retain the file and any metadata needed to identify its use, subject to their internal requirements and applicable rights. For assets that still depend on a retrieval operation, the documentation reviewed does not guarantee that the operation will remain available after the stated date.

Example: inventory and operational response

Suppose an internal service receives video requests, records the job ID, checks its status periodically, and, once the job is complete, downloads the content and sends it to a review system. The inventory should record each operation and each downstream destination separately. That way, the team can determine whether it depends on generating new videos, checking existing jobs, downloading files, or all three.

If the team retains only the job ID, it does not necessarily have a local copy of the video. If it retains the downloaded file, it can preserve that asset in its own storage, but that is not the same as keeping generation available or proving how long metadata will remain accessible in the service. The reference includes expires_at as data associated with downloadable assets; the source does not explain how that field would apply after retirement.

A controlled shutdown test could simulate failed responses or unavailability in a test environment and verify that the queue does not retry requests indefinitely, users receive an understandable status, and downstream processes do not mark a job complete when no file is present. This is an engineering recommendation, not a prediction about the API’s specific response. The documentation provided does not specify that response.

A migration has not been specified

The deprecations table does not list a replacement for the specified components. That does not prove that no other video-generation tools exist, but it does mean that, based on the sources reviewed, there is no basis for recommending a replacement as an official or compatible migration. Before choosing another solution, decision-makers should check which operations it offers, how it handles jobs, which formats it produces, what terms apply, and whether it meets security, cost, quality, and integration requirements.

Nor can these sources establish what will happen to jobs still pending on September 24, 2026, whether metadata will remain visible or for how long, or whether there will be exceptions or later schedule changes. The technical reference notes the scheduled date but does not detail the operational consequences of that day. If OpenAI publishes updates, those instructions should be reviewed before irreversible decisions are made.

For a service decision, the prudent approach is to separate what the team can control from what depends on the provider. The team can locate API calls, reduce new dependencies, back up assets already available to it, record its own metadata, and test how its systems behave when errors occur. It cannot infer from these actions that the endpoint will continue, that remote assets will be retained, or that an extension will be granted. Assign owners and internal deadlines to each task, and review the official documentation closer to the change.

Keep exploring

Corrections and transparency

If you spot incorrect or outdated information, send us a correction with the page and source we should review.