A video provider interface after the Sora shutdown, Sume behind it

OpenAI's deprecations page lists the Sora video API shutdown date as September 24, 2026 and names no recommended replacement (read 2026-10-03). Code that called it directly now needs a new backend; code that called it through one interface needs a new adapter. The interface below is small on purpose, shaped by what an async job API actually returns.

Shape the interface around jobs

Every hosted video API is asynchronous, so do not model generation as a function that returns a video. Model it as submit, then a handle you can persist, then a poll that yields a terminal state with output URLs. That maps directly to a Sume job: the submit returns a job id, GET /v1/jobs/:id/status reports terminal, and the result carries artifacts on media.sume.com.

export type VideoRequest = {
  prompt: string;
  imageUrl?: string;
  durationSeconds?: number;
  resolution?: "720p" | "1080p";
  idempotencyKey: string;
};

export type VideoStatus =
  | { state: "pending"; pollAfterSeconds?: number }
  | { state: "done"; urls: string[] }
  | { state: "failed"; code: string; retryable: boolean };

export interface VideoProvider {
  submit(req: VideoRequest): Promise<{ handle: string }>;
  status(handle: string): Promise<VideoStatus>;
  cancel(handle: string): Promise<void>;
}

What the Sume adapter maps

On Video 1.0, prompt, image_url, duration and resolution are documented request fields, and Idempotency-Key is the header for safe retries. Video 1.0 is documented as a retiring compatibility alias; for new code the docs point to POST /v1/videos with a catalog model id, so check the live OpenAPI before you hard-code a path.

Keep vendor quirks inside the adapter

Polling cadence, download URL lifetimes and size rules differ by vendor, so they belong in each adapter, not in callers. Run the same five prompts through every adapter in CI and record what differs; that is the exit drill, written as a test.