Sora API Shutdown: What to Do After September 24, 2026

The announced Sora API shutdown date, September 24, 2026, has passed. Stop sending new jobs to the retired route and check which outputs your application already retained. OpenAI's Sora web and app experiences ended on April 26, 2026; that earlier date is separate from the API deadline. OpenAI's discontinuation notice explains both dates and the app export process. An old API reference is not evidence that an endpoint or a historical video remains accessible.

Switching to Kling or Seedance involves more than selecting a new model. Request bodies, reference inputs, job states, result URLs, and supported durations can differ. The migration is complete when your application can submit, track, retrieve, and retain an acceptable video through the new route.

Shutdown guidance updated October 8, 2026. The Seedance submission example remains based on the published schema checked September 14; recheck the linked route documentation and account access before running it. No paid generation or legacy-asset recovery test was performed.

What to do after the Sora API shutdown

Start with your own job database, object storage, and backups. Preserve the provider job ID, your internal job ID, model, prompt, reference-asset locations, requested settings, last recorded status, and any downloaded output. Keep these records under your existing access and retention rules.

1. Verify saved videos. Open the files from storage you control, check playback, and confirm that your application no longer needs a Sora URL to retrieve them.
2. Separate unresolved jobs. A job ID or an old result URL does not prove that you have the media. Flag missing outputs and unknown states for investigation instead of marking them complete.
3. Disable legacy submissions and retries. Remove Sora from scheduled jobs and fallback routes. Keep unresolved job records separate from any newly authorized generation on a replacement service.
4. Check export or support options for missing assets. Follow OpenAI's current notice and account messages. Do not promise recovery, a deadline extension, or continuing API access without confirmation.

When matching historical API logs, distinguish the old job operations from the actual media download:

Historical purpose	Legacy OpenAI API path
Create a video	POST /v1/videos
Retrieve job metadata	GET /v1/videos/{video_id}
Download completed content	GET /v1/videos/{video_id}/content

The create, retrieve, and download references identify these historical operations. They do not establish post-shutdown availability. A saved metadata response is not a video archive; verify that the media bytes themselves are present in your storage.

For content made in the Sora app, OpenAI's notice directs users to the Sora export page and says an email follows when the export is ready. Check whether that option is available to your account. Do not assume an app export includes your application's API jobs. OpenAI describes possible final export windows and notification by email; the notice does not justify promising either immediate deletion of every asset on the API deadline or indefinite recovery afterward. Save any available export promptly and verify its contents.

Choose a replacement with the clips you actually produce

Begin with a small evaluation set representing your production work: a product close-up, a scene with motion, a reference-driven shot, dialogue if needed, and a difficult prompt your current workflow handles poorly. Keep input assets and acceptance criteria consistent across candidates.

Candidate	Documented capabilities worth testing	Migration questions
Kling 3.0	Native audio, multi-shot generation, and first/last-frame workflows in the official model guide	Does your chosen API route expose the required mode, duration, audio controls, and reference handling?
Seedance 2.5	Multimodal references, video editing and extension, and generation up to 30 seconds	Does the route support the requested resolution, reference roles, and task-specific parameter combination?

These are capability summaries, not quality rankings. See the Kling 3.0 model guide and ByteDance's Seedance 2.5 announcement. A capability available in a vendor application is not automatically available through every API or gateway.

Seedance and Seedream are different model families. Seedance generates video; Seedream 5.0 Pro is an image model. An image-generation price cannot be used as a per-second video quote.

Browse the Seedance 2.5 model page or the Tokenhot model catalog for candidate routes, then read the selected model's API page before implementing it. Record the exact model identifier and evaluation date so that later results can be compared meaningfully.

Adapt the request body, not just the base URL

The legacy Sora create operation used fields such as prompt, seconds, and size, with its own supported values. Tokenhot's documented Seedance 2.5 operation uses content, duration, ratio, and resolution instead. The Tokenhot path is /v1/video/generations, with singular video.

The following text-to-video submission follows the Tokenhot Seedance 2.5 documentation. That reference uses doubao-seedance-2.5, while the model catalog uses doubao-seedance-2-5. Confirm the accepted request ID for your account before running the example; the two spellings alone do not establish interchangeable aliases. Install requests, set TOKENHOT_API_KEY in your environment, and run it only when you intend to create a potentially billable job.

import json
import os
from pathlib import Path

import requests

record_path = Path("seedance-submission.json")
if record_path.exists():
    raise RuntimeError("A submission record exists; inspect it before creating another job.")

response = requests.post(
    "https://api.tokenhot.ai/v1/video/generations",
    headers={"Authorization": f"Bearer {os.environ['TOKENHOT_API_KEY']}"},
    json={
        "model": "doubao-seedance-2.5",
        "content": [{
            "type": "text",
            "text": "A ceramic cup on a wooden table, slow camera push-in, soft daylight."
        }],
        "duration": 5,
        "ratio": "16:9",
        "resolution": "720p",
        "generate_audio": False,
        "output_format": "mp4"
    },
    timeout=(10, 60),
)
response.raise_for_status()
job = response.json()
task_id = job["id"]
record_path.write_text(json.dumps(job, indent=2), encoding="utf-8")
print(f"Submitted task: {task_id}")

This example submits once and saves the response. A network timeout can leave submission outcome uncertain: the server may have accepted a job even though the client did not receive its ID. Investigate the existing request before submitting it again. The local file guard is a convenience for this example, not a production idempotency mechanism.

The current Seedance 2.5 page documents 480p and 720p output, with durations from 4 to 30 seconds or an adaptive value of -1. Video editing requires duration=-1 and ratio=adaptive; first-frame, first-and-last-frame, and extension tasks also require the adaptive ratio. Validate the rules for your task type rather than copying a text-to-video payload into every mode. Unsupported combinations may fail after asynchronous processing begins. Tokenhot parameter requirements.

Keep submission and polling schemas separate

An accepted submission is not a completed video. The Seedance 2.5 submission page documents a top-level id and statuses including queued, processing, succeeded, and failed.

The separately published Seedance 2.0 task-query page documents GET /v1/video/generations/{task_id} and illustrates a nested response: data.status is SUCCESS, while data.result_url contains the output address. Because that page is labeled for 2.0, confirm the query contract for your selected 2.5 route before reusing a 2.0 polling parser.

Build a small adapter for each verified route. It should translate the provider response into your application's own states, such as waiting, running, completed, and failed. Preserve the raw task ID and error details for troubleshooting. Unknown states should trigger investigation rather than being treated as success.

Your worker should have a bounded polling interval, an overall deadline, and explicit handling for authentication errors, throttling, and transient server failures. When a local polling deadline expires, retain the job ID so that another worker can resume checking it. Do not submit a replacement job merely because the original has taken longer than expected.

Once a job succeeds, retrieve the result promptly and save it under your application's retention policy. Treat signed output URLs as temporary access mechanisms unless the service explicitly documents otherwise. A completed provider job and a safely retained customer asset are separate milestones.

Compare cost per accepted clip

Compare prices for the same resolution, duration, audio setting, input mode, and access route. Vendor app credits, direct API prices, and gateway quotes can use different billing rules. Our API pricing comparison explains how to keep billing units and provider routes separate.

A useful evaluation metric is:

Cost per accepted clip = total billed evaluation cost / accepted clips

For example, if an evaluation costs $12 and yields eight clips that pass your requirements, the observed cost is $1.50 per accepted clip. This is an illustrative calculation, not a Kling or Seedance price quote. Include billed rejected attempts in the numerator, and separately account for storage, editing, and human review if they affect your decision.

Track completion time and failure rate alongside visual quality. A low list price offers little help if your workflow repeatedly regenerates unusable outputs.

Validate the replacement before restoring production traffic

1. Verify retained Sora outputs and record missing assets separately.
2. Select a replacement route using representative clips and explicit acceptance criteria.
3. Verify request validation, submission records, query parsing, failed jobs, and output retrieval.
4. Send a controlled batch of new work to the replacement and inspect completed assets, cost, and failures before expanding traffic.
5. Check that queues, scheduled jobs, and fallback rules no longer create Sora requests.
6. Keep the old job records readable and use a fallback that does not depend on Sora access or recovery of missing outputs.

If you are also choosing a gateway, the OpenRouter alternatives guide covers route selection and compatibility checks. For implementation, start with the exact video-model page in the Tokenhot API documentation, then validate the complete job lifecycle in your own environment.