Point an OpenRouter-style video client at Sume: what changes

A client written for the OpenRouter video generation API works against Sume after you change the base URL, the key and the model ids. Sume's /v1/videos follows that API field for field, and its docs list the handful of places it differs. Fix those and the rest of your code, including polling, stays as it was.

This helps when a launch week sends you hunting for the model that does what you need. Keeping one client means a new model is a catalog id, not a rewrite. Everything here is from Sume's video generation docs, read 2026-10-02. It is a wire-compatibility note, not a partnership or an endorsement by either side.

What do I change first?

Three values. The base URL becomes https://api.sume.com/v1/videos, with no /api segment. The header becomes Authorization: Bearer $SUME_API_KEY. Model ids become bare catalog ids such as seedance-2, because Sume's published contract never carries a provider-org prefix.

Which differences can break a working client?

The table lists the documented deltas that change behavior. Check your code for each one.

What can I add that the other API lacks?

Sume adds model: "sume/auto", which lets Sume pick the family and echoes sume/auto back. It also exposes the same job at GET /v1/jobs/{id}/status and GET /v1/jobs/{id}/result. Neither is needed for a basic port.

How do I test the port?

Submit one short clip with a pinned id, poll the polling_url until completed, then download from unsigned_urls[0]. Run it with your normal prompt and compare the fields you rely on. If a 400 appears, read the field name against the table above before changing anything else.