Pointing the OpenAI SDK at api.sume.com: why Sora calls still fail

No, changing the OpenAI client's base URL to https://api.sume.com will not make a Sora videos call work, and I did not find a Sume page that says it should. Sume's /v1/videos follows the OpenRouter video wire, which differs from the OpenAI Videos API the guide documents: model ids, body format, the seconds and size fields, status words and the download call.

I did not test the OpenAI SDK against Sume. The differences below come from reading the two vendors' pages on 2026-10-08, and the script at the end lets you see Sume's answer to a Sora-shaped body for yourself.

Five differences

The OpenAI deprecations page also lists the Videos API as removed on September 24, 2026, so even a perfect shim would have nothing to talk to on the other side.

What the SDK helper would hide

A helper such as create_and_poll loops until a status it knows. If Sume returned pending, a loop written for queued would not recognise it. Even a successful create would then fail at the download step, because Sume wants the key on the request to /content and answers 302.

The practical fix is the one in the mapping post: write a thin adapter in your own code that speaks Sume's wire and keep your call sites unchanged.

See the answer yourself

This sends a Sora-shaped body to Sume and prints the status code and the error text. Sume rejects it before any generation starts, so no job is created from this body. Set SUME_API_KEY first.

import json, os, urllib.error, urllib.request

def main():
    body = {"model": "sora-2", "prompt": "A test", "seconds": "8", "size": "1280x720"}
    req = urllib.request.Request(
        "https://api.sume.com/v1/videos", method="POST", data=json.dumps(body).encode(),
        headers={"Authorization": "Bearer " + os.environ["SUME_API_KEY"],
                 "Content-Type": "application/json"})
    try:
        urllib.request.urlopen(req)
    except urllib.error.HTTPError as err:
        print(err.code, err.read().decode())

main()