Sora ended in two steps: app in April, API on September 24

OpenAI's docs say the Sora API shut down Sep 24, 2026 with no direct replacement. A help-center snippet dates the app and web end at Apr 26. What to inventory.

4 min readSume
All posts

OpenAI's video generation guide states that the Sora API shut down on September 24, 2026 and that there is no direct replacement API. A search snippet from OpenAI's help center dates the end of the Sora app and web experience at April 26, 2026, which is 151 days earlier. We could not open the help page itself (it returned 403), so treat the April date as a snippet, not a confirmed reading.

Sora end dates (read 2026-10-03)
SurfaceEnd dateSource quality
App and webApr 26, 2026Search snippet of the help center; page returned 403
APISep 24, 2026OpenAI developer docs, read directly

Why two dates matter

Teams that only used the app lost their workflow in April. Teams that called the API kept working for five more months, which made the shutdown easy to forget. If your scheduled jobs, agent tool configs or internal docs still mention Sora, they now fail at the first call.

The absence of a replacement API is the harder part. A migration cannot be a base URL swap, because nothing at OpenAI accepts the old requests. You pick a new vendor and adapt the request shape.

An inventory checklist

Work through these in order. Each one hides a dependency that surfaces only when it breaks.

  • Code: every call that builds a video request, including helper libraries and old notebooks.
  • Saved outputs: files that existed only in a vendor-side library, which may no longer be reachable.
  • Schedules: cron jobs, workflow nodes and automations that submit video requests unattended.
  • Agent configs: MCP servers, tool lists and system prompts that name Sora as a capability.
  • Budgets and alerts: spend dashboards that still expect a Sora line item.
  • Templates: prompt libraries written around one model's habits, which need a rewrite for the next.

What a replacement call looks like on Sume

Sume's video route is asynchronous: you submit to POST /v1/videos, receive a job id and a polling URL, poll until the status is completed, then download. The same job is also visible at GET /v1/jobs/{id}/status. A Higgsfield migration guide published in October describes the same submit, poll, download shape for its own API, which is the pattern most video APIs share.

Model ids on Sume are bare catalog ids such as seedance-2.5, with durations and resolutions that differ per model, so read GET /v1/videos/models before you map old durations onto new ones.

curl -s -X POST https://api.sume.com/v1/videos \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: sora-exit-test-001" \
  -d '{"model":"seedance-2.5","prompt":"A paper boat on a wet street","duration":6,"resolution":"720p","aspect_ratio":"16:9"}'

What to do this week

Run the inventory, pick two candidate models and send one short clip to each. Keep the old prompt library, but expect to edit it. If a vendor exit in your stack would stop revenue, write down the replacement model before the next notice, not after it.

Sources

Related posts

More in Developers

All Developers posts

Written by Sume