OpenAI named no Videos API replacement: build it swappable

OpenAI's deprecations page lists sora-2, sora-2-pro, their dated snapshots and the Videos API with a 2026-09-24 shutdown and no recommended replacement. For the image models in the same page, OpenAI does name replacements. That difference is the lesson: when a vendor gives you no path, your code must supply one. Put video generation behind one interface, read model ids and limits from a catalog at runtime, and keep every vendor id in config.

What the page says, side by side

The same deprecations page treats video and image models differently, which is worth seeing before you plan work.

Three seams to cut

First, one function signature for your own app: prompt, duration, aspect ratio, optional first frame, returns a job handle. Second, a model registry in config that maps your product tiers to catalog ids. Third, a normalizer that turns each vendor's status words into your own four: pending, running, done, failed.

• Never branch on a model id outside the registry.
• Never hard-code a duration or resolution list; read it.
• Never store a vendor's temporary URL as the asset of record.

Discovery instead of hard-coding

Sume publishes GET /v1/videos/models, and each entry lists supported_resolutions, supported_aspect_ratios, supported_durations, supported_frame_images, supported_input_references, generate_audio and pricing_skus. The video generation docs say limits are not uniform across models, so your validator should read this list rather than assume one envelope. The Video Router docs describe the same catalog on the older route.

What this does and does not buy you

A swappable backend means a vendor exit costs a config change plus a regression pass, not a rewrite. It does not make outputs identical across models: prompts tuned for one model will read differently on another, so keep a small set of golden prompts and compare. For the wire details, the API reference points to the live OpenAPI document as the source of truth.