OpenAI Kills the Videos API With No Successor: A 4-Week Exit Plan

On 2026-09-24, OpenAI shuts down the Videos API and every sora-2 model behind it. That sentence alone would make this a routine migration story, the kind teams handle with a model-ID swap and a regression run. What makes it a different kind of story is one column on one page. OpenAI's own deprecations page lists a recommended replacement for nearly every 2026 retirement it announces. For the Videos API and all five sora-2 model aliases, that column is empty.

We re-checked the page on 2026-08-28. The rows are: the Videos API endpoint itself, sora-2, sora-2-pro, sora-2-2025-10-06, sora-2-2025-12-08, and sora-2-pro-2025-10-06. Shutdown date for all six: 2026-09-24. Recommended replacement for all six: none listed. The deprecation was announced 2026-03-24, so the full window was six months. As of this writing, 27 days of it remain.

If your product generates video through OpenAI, you do not have a migration ahead of you. You have a decision, and the vendor has explicitly declined to make it for you.

The Real Business Bottleneck#

The empty replacement column changes the economics of the shutdown, and it is worth being precise about how, because the same page shows what a normal retirement looks like.

Every other major 2026 deprecation on that page names a successor. The Assistants API was sunset on 2026-08-26 with a documented path to the Responses and Conversations APIs, which we walked through in our Assistants API port guide. The audio and realtime model family retires 2027-01-20 with named replacements, gpt-realtime-2.1 and gpt-audio-1.5, covered in our model-ID audit. Legacy GPT snapshots die 2026-10-23 pointing at the gpt-5.6 family, the subject of our snapshot-pinning audit. In each of those cases the vendor bounded your cost: the work is an inventory scan, an ID swap, and a behavioral regression pass. Annoying, but estimable.

A retirement with no successor removes that bound. Three costs open up at once.

The cost exposure stops being an engineering line item and becomes a product decision. There is no like-for-like swap to price. Your options are re-platforming onto a different vendor's video stack, which means new prompts, new output characteristics, new billing, and new failure modes, or removing the feature, which means confronting what it actually earns.

The reliability exposure has a hard date. On 2026-09-24 the endpoint stops answering. A customer-facing feature backed by /v1/videos does not degrade gracefully after that; it returns errors. If video generation sits anywhere in a paid workflow, an onboarding flow, or a contractual deliverable, the shutdown date is an outage date unless you act first.

The third bottleneck is decision latency, and right now it is the binding one. Re-platforming a video feature in 27 days is possible but tight. Re-platforming it in the final week is not. Every day spent treating this as "a migration we'll schedule" rather than "a decision we make this week" spends the only budget that cannot be topped up.

Why the Naive Fix Fails#

The reflex response to a deprecation notice is a config change: find the model string, replace it with the successor, ship. Teams have done this so often in 2026 that it feels like the whole job. Here it fails immediately, for a reason you can verify in thirty seconds: there is no successor string to paste. The vendor's own table offers nothing to swap to.

The second naive move is to reach for a "best Sora alternatives" listicle and treat its top entry as the replacement. This fails more slowly but more expensively. Those pages are search-engine content, not engineering evidence. They rarely distinguish a consumer app from a developer API, they go stale as vendors reshuffle models, and they say nothing about whether an alternative's output characteristics survive contact with your prompts, your aspect ratios, your content policies, or your latency budget. Picking a re-platform target from a listicle converts an unbounded decision into an unexamined one, which is worse.

The third naive move is to do nothing and assume OpenAI will extend the date or ship a successor before the deadline. Maybe. But the announcement is five months old, the window is nearly spent, and the replacement column has stayed empty the entire time. A plan whose first step is "the vendor changes its mind" is not a plan.

What actually works is boring and fast: inventory what you have, then run each usage through a three-way decision. Both steps are small enough to finish this week.

Production Architecture: The Inventory Scan and the Exit Matrix#

Step 1: Find every touchpoint#

The scan is deliberately trivial. There are exactly six literal strings to find: the endpoint path and the five model aliases. One grep over source, config, and environment files surfaces all of them. We ran this against a synthetic fixture repo to show the shape of the output:

grep -rnE 'sora-2(-pro)?(-2025-(10-06|12-08))?|/v1/videos|videos\.create' . \
  --include='*.py' --include='*.yaml' --include='.env*'

Output from our fixture:

./app/video_service.py:3:VIDEO_MODEL = "sora-2-pro"
./app/video_service.py:7:    return client.videos.create(model=VIDEO_MODEL, prompt=prompt)
./config/models.yaml:2:  primary: sora-2-2025-12-08
./config/models.yaml:3:  fallback: sora-2
./.env.example:1:OPENAI_VIDEO_MODEL=sora-2

Note the third line of that fixture: a "fallback" from one sora-2 alias to another. Every hit in that file dies on the same day, so a fallback chain that never leaves the sora-2 family is not redundancy, it is the same outage written twice. Extend the include patterns to whatever languages your stack uses (*.ts, *.rb, *.go), and check your infrastructure-as-code and CI variables too, since model IDs hide in deployment config as often as in code.

Label every hit with the feature it serves and whether that feature is customer-facing, internal, or dormant. That labeled list is the input to step 2.

Step 2: Run each usage through the exit matrix#

With no vendor-recommended path, each usage lands in one of three rows. This matrix is built from the deprecations page's own structure: what the vendor removed, what it did not name, and what that leaves you.

The middle row is the one teams forget exists. If your "video generation feature" in practice renders a few hundred variants of known templates, you do not need a video API after September; you need the outputs, generated once, while the API still answers. That converts an ongoing vendor dependency into a static asset problem and can be executed in days.

Step 3: If you re-platform, do it behind a seam#

For the re-platform row, two vendors currently document developer video-generation APIs in their own materials. Google's Gemini API video generation docs document Gemini Omni Flash and Veo 3.1 as video-generation models served through their API. Runway's developer API documentation documents video endpoints, including /v1/image_to_video and /v1/video_to_video, with Node.js and Python SDKs. Both statements are source-verified from vendor documentation only. We have run no video-generation benchmark, so we make no claim about either vendor's output quality, latency, or cost relative to sora-2, and neither should you until your own prompts have been through them.

That uncertainty is exactly why the architecture matters more than the vendor choice. The teams hurt most by this shutdown are the ones that called client.videos.create directly from feature code. Whatever you migrate to, put a seam in first:

class VideoBackend(Protocol):
    def generate(self, req: VideoRequest) -> VideoResult: ...

# feature code depends on VideoBackend, never on a vendor SDK.
# Swapping vendors becomes one adapter, not a codebase sweep.

An adapter interface with a vendor-neutral request type costs an afternoon. It is the difference between this article's grep being your last vendor-shutdown scramble and merely your most recent one.

Financial and ROI Impact for Founders#

The money question here is not "what does migration cost." It is "does this feature justify existing on someone else's stack at all," and the shutdown forces you to answer it with real numbers for the first time.

Work the decision in this order. First, attribute revenue: which paying customers touch the video feature, and what churns if it disappears? If the honest answer is "we are not sure anyone would notice," the drop row costs you almost nothing and the exercise just saved you a re-platforming project. Second, check the freeze row before pricing the re-platform row: a bounded generation batch executed before 2026-09-24 is often two orders of magnitude simpler than a vendor migration, and it buys you time to re-platform later with no deadline pressure. Third, if the feature genuinely earns open-ended generation, the re-platform cost is dominated not by the SDK swap but by prompt and output re-validation, so budget engineering time for a structured comparison of candidate vendors on your own workload rather than trusting anyone's marketing page, ours included.

There is also a portfolio lesson with ROI beyond this incident. The deprecations page now contains both retirement patterns: capability retired with a named successor, and capability retired with none. The first is an engineering cost. The second is a product risk. Any AI feature you ship on a single vendor's API carries some probability of the second pattern, and the cheap insurance is the seam from step 3 plus a quarterly inventory scan like step 1. Teams that had those two things in place read this announcement calmly. Teams that did not are reading it 27 days out.

Can this survive your workflow?#

Before you file this under handled, check:

• Has the grep from step 1 actually been run against every repo, including infra config, and did someone label each hit with the feature and revenue behind it?
• Does any fallback chain in your config fail over from one sora-2 alias to another, which is no fallback at all after 2026-09-24?
• If you chose the freeze row, is the pre-generation batch scheduled to finish with margin before the shutdown, not on its eve?
• If you chose re-platforming, does feature code now depend on an adapter rather than a vendor SDK, and has anyone validated the new vendor's output on your real prompts rather than on a demo?
• Is someone re-checking the deprecations page weekly until 2026-09-24, in case the date or the empty column changes?

When to Use, When to Skip#

Use this playbook now if any code path in your product calls /v1/videos or names a sora-2 model. The date is fixed, the vendor path is absent, and the decision compresses badly as the window closes.

Skip it if you have no OpenAI video usage; then this is a case study in vendor-sunset risk worth ten minutes, not a work item. And skip the re-platform row specifically if your usage fits the freeze row; taking on a new video vendor to keep serving a bounded set of template clips is buying an ongoing dependency you demonstrably do not need.

For Your Engineers#

The load-bearing facts, so your team verifies rather than trusts: OpenAI's deprecations page lists the Videos API and the aliases sora-2, sora-2-pro, sora-2-2025-10-06, sora-2-2025-12-08, and sora-2-pro-2025-10-06 with shutdown 2026-09-24, announced 2026-03-24, and an empty recommended-replacement column for every row, in contrast to the same page's Assistants, audio/realtime, and legacy-snapshot entries, which all name successors. Google documents Gemini Omni Flash and Veo 3.1 for video generation in the Gemini API docs; Runway documents video endpoints and SDKs at docs.dev.runwayml.com. The inventory scan is the six-literal grep shown above, executed here against a synthetic fixture with its real output pasted. Re-fetch the deprecations page before acting; dates on that page are the vendor's to move.

What Effloow added: the contrast reading of the deprecations table (absence-of-successor as the finding, verified 2026-08-28), the three-row exit matrix with the usually-missed keep-and-freeze path, the tested inventory scan with fixture output, and the adapter-seam pattern. We have no Sora production usage and have benchmarked no video vendor, so no quality or cost comparison appears here, and any vendor named is cited to its own documentation only.

Effloow does exactly this kind of work for AI products under deadline: inventory the exposure, build the evidence-bound decision artifact, and execute the exit before the vendor's date. If the 2026-09-24 shutdown touches your product and the build-or-abandon call is still open, see how we work, review the approach on Proof Studio, or get in touch this week rather than in week four.