OpenAI Video API Shuts Down September 24: What to Change in Your Code

OpenAI set a removal date and left the successor blank

A render worker polls GET /videos/{video_id} every ten seconds, the way OpenAI's guide suggests. When the status flips to completed, it streams the MP4 into storage. Nobody has touched it in months.

OpenAI's deprecations page schedules the endpoint it polls, and the Sora 2 models behind it, for removal on September 24, 2026.

The notice is not new. OpenAI dated it March 24, 2026, six months ahead of the cutoff. What is unusual is the column beside it. The page says it lists every deprecation along with a recommended replacement, and for all six rows in this entry that column reads ---.

So this is a migration without a map. This guide is for the engineer who owns the code, not the ad team picking a new look; that question has its own guide to switching video models. Every destination below is our recommendation, not OpenAI's, and we publish one of the APIs covered. Here is what the guide walks through:

• What the deprecations page removes, row by row.
• The exact call shape your integration loses.
• The destinations we checked, each with its own request shape.
• A field-by-field mapping, then a worked migration with real queue numbers.
• The switching costs that never make it into a changelog.

What OpenAI's deprecations page removes on September 24

The entry sits under a dated heading, "2026-03-24: Sora 2 video generation models and Videos API". OpenAI's video generation guide repeats the date in a banner: the models and the Videos API are deprecated and will shut down on September 24, 2026.

Six rows share one shutdown date

The table under the notice has six rows, and each one carries the shutdown date 2026-09-24:

• The Videos API itself, which means the endpoints go, not only the models behind them.
• sora-2 and sora-2-pro, the two aliases.
• sora-2-2025-10-06 and sora-2-2025-12-08, two dated sora-2 snapshots.
• sora-2-pro-2025-10-06, a dated sora-2-pro snapshot.

Pinning a snapshot does not help here. The snapshots sit on the same list as the aliases, with the same date.

The replacement column reads three dashes

OpenAI describes the page as a list of all API deprecations "along with recommended replacements". Every row in this entry has a replacement cell, and every one of those cells reads ---.

Read that narrowly: this page names no successor for these six rows. It does not say OpenAI has no video capability anywhere.

The same page carries one general escape hatch. In some cases, it says, developers may be able to provision dedicated capacity for continued access after a model's shutdown date, through OpenAI's sales team. It does not say whether that applies here. Unless your volume justifies that conversation, plan as if the date is final.

A reseller moves the request, not the deadline

If your code reaches the model through a host, the date still applies. fal's Sora 2 text-to-video page says "This endpoint will be shut down on September 24, 2026." and marks the endpoint deprecated.

Our reading: a host resells what the model maker serves, so it loses the model the same day. A multi-model host can still be a sensible landing spot, for the other models it carries.

The call shape your integration is about to lose

Swapping the model string is the easy part; the contract around it is what breaks. OpenAI's guide describes a video call in three steps, and each one carries an assumption your code has baked in.

Create: a multipart form with size and seconds

You POST /videos with a prompt and a few parameters. In OpenAI's words, "parameters like size and seconds control the video's resolution and length". The guide's curl example sends a multipart form:

curl -X POST "https://api.openai.com/v1/videos" \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: multipart/form-data" \
  -F prompt="Wide tracking shot of a teal coupe driving through a desert highway, heat ripples visible, hard sun overhead." \
  -F model="sora-2-pro" \
  -F size="1280x720" \
  -F seconds="8"

The response is a JSON job with an id and an initial status such as queued or in_progress. Three details matter for the mapping later:

• size is a pixel string such as 1280x720, not a ratio.
• Length is a string. The job object echoes it back as "seconds": "8".
• The first frame is a file part. Image-guided jobs send input_reference as an upload in multipart requests.

Wait: poll the job or take a webhook

Then you wait. Typical states are queued, in_progress, completed and failed, and the guide offers two routes to the end state:

• Poll GET /videos/{video_id} until the status transitions to completed. OpenAI suggests every 10 to 20 seconds, with exponential backoff when needed.
• Webhook. When a job finishes, the API emits video.completed or video.failed, each carrying the job id.

If your integration took the webhook route, flag it now. It has the weakest equivalent at the destinations covered below. The submit-then-wait shape itself is common; our walkthrough of the Higgsfield API's queue and retention rules documents another vendor's version of it.

Collect: stream the MP4, then copy it

Once the job is completed, GET /videos/{video_id}/content streams the MP4. A variant query parameter returns a thumbnail or a spritesheet instead of the video. The guide adds that download URLs are valid for a maximum of 1 hour after generation, and tells you to copy files to your own storage promptly.

That advice shapes the migration. A pipeline that followed it already holds its files, so September 24 means replacing a code path, not rescuing an archive. If yours kept OpenAI video ids instead, fetch what you still need before the date; the endpoint that serves them is on the removal list.

The surface beyond create, poll and download

Most real integrations touch more than the three core calls. Inventory these before you pick a destination, because each one needs its own answer there:

• Extensions at POST /v1/videos/extensions. Each extension can add up to 20 seconds, for a maximum total length of 120 seconds.
• Edits at POST /v1/videos/edits, which take a prompt and a video reference for one targeted change.
• Characters at POST /v1/videos/characters, where a short MP4 clip becomes a reusable character id.
• Batch, where the Batch API supports POST /v1/videos only, for offline render queues.
• Long takes. The guide says both sora-2 and sora-2-pro support 16- and 20-second generations.

A team that only called create, poll and download has a small migration; one that built on extensions or characters has a redesign. How the models compare on output quality is a separate question, covered in our retrospective head-to-head of Seedance 2.0 and Sora 2.

Where your video calls can go: our shortlist

OpenAI names no destination, so the picks here are ours. Our test: a model id that is not deprecated as of September 21, 2026, callable from your own code, with its request shape in public docs we read for this guide. Two providers passed with sourced docs, Google's Gemini API and the Novoads REST API. Other vendors, or open weights you host yourself such as LTX-2.3, may fit; we did not source their API docs, so we do not rank them.

Google's Gemini API: Omni Flash is the default

Google's video overview offers two models and says to "use Gemini Omni Flash as your default model for video generation", with Veo 3.1 for scene extension, last-frame control or legacy pipelines.

The id matters more than the name. Google's model page lists gemini-omni-1.1-flash as stable and gemini-omni-flash-preview as the preview. Its deprecations page gives the preview a shutdown date of September 30, 2026, with gemini-omni-1.1-flash as the replacement, and lists no shutdown date for the stable id. Moving off one removal onto another that lands six days later is the mistake worth ruling out by name. Our Gemini Omni Flash explainer covers what changed in the stable release.

The call shape is new again:

• Endpoint: POST /v1beta/interactions, with a JSON body carrying model and input.
• Frame shape: a response_format object whose aspect_ratio takes "9:16" or "16:9"; landscape is the default.
• Length: output runs 3 to 10 seconds, per Google's model page.
• Result: over REST, the video comes back base64-encoded inside the interaction's steps array. For videos larger than 4MB, Google says to request delivery="uri" and poll the returned file until it is ACTIVE.

Veo 3.1 on the Gemini API: a long-running operation

Veo 3.1 uses a third shape, and its budget tier, Veo 3.1 Lite, takes the same call with a different model string. You POST to /models/veo-3.1-generate-preview:predictLongRunning with an instances array (the prompt, plus an optional image to animate) and a parameters object (aspectRatio, durationSeconds, resolution). The call returns an operation name. You poll the operation, check its done field, then read the file location from response.generateVideoResponse.generatedSamples[0].video.uri.

Three details change your code:

1. durationSeconds takes "4", "6" or "8", and must be "8" with extension, reference images, 1080p or 4k.
2. Files expire. Google says generated videos are stored on the server for 2 days, then removed.
3. The ids are previews. Google's deprecations page groups the Veo 3.1 ids under preview models, each with no shutdown date announced. That is not a warning sign, but it belongs in your runbook.

The Novoads REST API: one endpoint, five video models

The second destination is ours. Novoads is an AI video ad generator, and its REST API puts five video models behind one key and one request shape. The mapping below uses its live OpenAPI spec, version 2.27.0 as fetched on September 21, 2026; a later section covers what the API does and does not do.

Mapping the Videos API call, field by field

Here is the same job expressed three ways. The OpenAI column comes from its video guide, the Gemini column from Google's Veo 3.1 guide and the Novoads column from the 2.27.0 spec.

Step	OpenAI Videos API	Gemini API, Veo 3.1	Novoads REST API
Create	POST /videos	:predictLongRunning	POST /videos
Body	Multipart form (guide example)	JSON instances, parameters	JSON
Model	sora-2-pro	veo-3.1-generate-preview	veo-3.1 or seedance-2.0
Length	seconds: "8"	durationSeconds: "8"	durationSeconds: 8
Frame shape	size: "1280x720"	aspectRatio: "16:9"	aspectRatio: "16:9"
First frame	input_reference	image	startImageAssetId
Job handle	id	Operation name	jobId
Check status	GET /videos/{video_id}	Poll operation done	GET /generations/{jobId}
Finished when	completed or failed	done is true	Four terminal statuses
Completion notice	video.completed webhook	Polling, per the guide	Polling only
Download	GET /videos/{video_id}/content	video.uri in response	GET /generations/{jobId}/watch

Pixel sizes become a ratio plus a resolution

The size field disappears on both sides. A 1280x720 job becomes aspectRatio: "16:9", and a 1080x1920 job becomes "9:16". Resolution moves into its own field where one exists.

In the 2.27.0 spec, seedance-2.0 takes resolution from 480p up to 4k and defaults to 720p, and the spec flags that this field, unlike aspectRatio, changes the price. seedance-2.5 takes 480p or 720p. The veo-3.1, omni-flash and seedance-2.0-mini bodies carry no resolution field at all. If your old jobs asked for 1920x1080, that narrows your model choice before quality even enters the conversation.

Durations are a grid, and off-grid is an error

OpenAI's guide allowed 16- and 20-second generations. The destinations fix a grid per model instead. The Novoads spec is explicit that "a duration a model does not render is an error, not a rounded request", and its grids are:

• seedance-2.0 and seedance-2.0-mini: any whole second from 4 to 15.
• seedance-2.5: any whole second from 4 to 30, the only id in the spec that takes a 20-second job whole.
• omni-flash: 4, 6, 8 or 10 seconds.
• veo-3.1: 4, 6 or 8 seconds.

So audit your seconds values before you map models. A 20-second shot either moves to seedance-2.5 or gets split into takes. If long single takes are the reason you used the old API, what Seedance 2.5 does with 30-second clips is the relevant read.

A worked migration: one render, then a queue of forty

Take the guide's own example job: sora-2-pro, 1280x720, 8 seconds, a teal coupe on a desert highway. Here it is on the Novoads API, with the same prompt and shape:

curl -s "https://api.novoads.ai/v1/videos" \
  -H "Authorization: Bearer $NOVOADS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "seedance-2.0", "aspectRatio": "16:9",
       "durationSeconds": 8, "resolution": "720p",
       "prompt": "Wide tracking shot of a teal coupe driving through a desert highway, heat ripples visible, hard sun overhead."}'

Four things changed:

1. Encoding: a JSON body instead of the guide's multipart form (a caller already on OpenAI's JSON form keeps it).
2. Shape: a ratio plus a resolution instead of a pixel string.
3. Length: an integer on the model's grid instead of a string.
4. Handle: a jobId you poll at GET /generations/{jobId} until it is terminal, then fetch through GET /generations/{jobId}/watch, a redirect to a freshly signed download URL.

The single job

Price it first. POST /estimates mirrors the generation request and, per the spec, "spends nothing and creates no job." For scale, a Novoads clip runs from about 25 cents for a five-second Seedance 2.0 Mini clip to about $4 for an eight-second Google Veo 3.1 clip, and about $10 for a full 30-second Seedance 2.5 take. If you are comparing that against a per-second bill elsewhere, our guide to how AI video credits compare across vendors does the unit conversion.

Store the jobId before anything else. The spec warns that if a call times out, the work may still have run and been charged, and GET /generations is the recovery path.

The queue of forty

Now the batch. Say the old worker pushed 40 of these jobs every morning through a render queue. Three numbers from the spec set the new schedule:

• Concurrency: generation is capped at 5 jobs in flight per organization.
• Render time: the spec gives 4 to 7 minutes as typical for video.
• Rate limit: 60 requests per minute per key.

The queue equation: waves = jobs ÷ concurrency, so 40 ÷ 5 = 8 waves. At 4 to 7 minutes a wave, the batch takes roughly 32 to 56 minutes of wall clock if you keep all five slots full. Polling five jobs every 10 seconds costs 30 requests a minute, half the per-key ceiling, so polling is not your bottleneck. The concurrency cap is. A sixth submission returns a 429 with the reason concurrency_limit, which means your submitter wants a five-slot semaphore, not a retry loop.

That is the whole port for a simple integration: one request builder, one poller, one semaphore.

The switching costs nobody lists in a changelog

Every migration guide covers the happy path. These are the three places a team actually loses a day.

Your webhook handler becomes a poll loop

On OpenAI you could wait for video.completed. The flows in the docs we read replace it with polling: the Veo guide polls an operation, Omni Flash returns the video inline or as a file you poll, and the Novoads 2.27.0 spec ships an empty webhooks object, so a Novoads caller polls GET /generations/{jobId}. The spec says that status call also drives completion when a provider's own callback is dropped, and that its rate limit is sized for polling every few seconds.

The cheap fix: keep the idempotent "job finished" handler your webhook called, and call it from a poll loop instead of an HTTP route. Downstream code never notices.

Terminal states multiply

OpenAI's loop exits on completed or failed. Novoads has four terminal statuses: succeeded, failed, blocked and canceled. The spec says it bluntly: a loop that waits only for success never exits on a job that failed. Branch on all four, or your worker hangs on the first job that ends any other way.

A job sitting at queued is a different case. The spec calls that normal, not a stall, so do not time it out on the old API's rhythm.

Features you rebuild rather than port

Walk back through the inventory:

• Extensions. Google says you can use Veo 3.1 to extend videos you previously generated with Veo by 7 seconds, up to 20 times. On Novoads, the answer is a longer grid: seedance-2.5 renders up to 30 seconds in one take.
• Characters. On Novoads, referenceAssetIds on the Seedance models composites several uploaded images, such as the character, the product, the wardrobe and the setting, addressed in the prompt as @Image1, @Image2 and so on. Veo 3.1 on the Gemini API accepts up to three reference images.
• Edits. Omni Flash on the Gemini API is built for conversational editing through the Interactions API, refining a video over several turns.
• Batch. Rebuild it as your own queue with a concurrency cap, as in the worked example above.

How Novoads solves the missing successor

Novoads gives a team leaving OpenAI's Videos API five video models behind one key and one request shape: seedance-2.0, seedance-2.5, seedance-2.0-mini, omni-flash and veo-3.1. The full contract, per-model grids included, is in the Novoads API reference. What you get:

• One default. Omit model and you get seedance-2.0.
• A price check before every spend. GET /models lists every model with its grid and price, and POST /estimates quotes a call without running it.
• Ad-shaped inputs. startImageAssetId animates your own product photo as the opening frame, and the Seedance reference images put a product and a person in one scene.
• One credential. Every endpoint takes a bearer key minted in the dashboard under Settings, then Developer.

If you are choosing between the two model families for ad work, our comparison of Seedance and Veo for UGC ads runs the numbers. An agent can drive the same endpoints, as in this five-stage Claude Code ad workflow.

The limits, stated plainly so you can plan around them:

• API calls draw from the same credit balance as the dashboard, and access requires a live Novoads subscription. The plans are published on novoads.ai/pricing.
• There are no webhooks; you poll.
• Generation is capped at five jobs in flight per organization, and typical renders take 4 to 7 minutes.

Migrate the contract, not the model name

The deprecation table makes this look like a one-string change. It is not. The model id is the smallest part of a video integration. The frame shape, the duration grid, the status vocabulary and the way your code learns a job is done are the real surface, and all four move on September 24.

Map those four first and the removal date is a quiet Thursday. Swap only the string and you find out from your error logs.

A model was always going to be temporary. The contract you write around it is the part worth getting right. If the five-model endpoint fits your pipeline, you can start building on Novoads today.