Migrate POST /v1/video-router/generate to /v1/videos: a field map

Moving a client from POST /v1/video-router/generate to POST /v1/videos is a path-and-body change with no model id remapping. Sume's docs say the legacy route creates the same jobs with the same ids, and that the difference is the wire: Video Router returns Sume's { "data": ... } job envelope and takes flat image_url and reference_image_urls fields, while /v1/videos returns the OpenRouter-shaped response and takes frame_images and input_references.

The legacy route still works unchanged, so there is no deadline in the docs. New integrations should use /v1/videos.

The field map

The first column is what your Video Router code sends today; the second is the replacement.

Things that change on the new route

Four behaviours differ from OpenRouter, and they apply to the new route. size returns 400 unsupported_parameter because every v1 model reports supported_sizes: null; use resolution and aspect_ratio. A non-empty provider.options is rejected, and no v1 model accepts seed. Webhooks use Sume's own job envelope with x-sume-webhook-signature, not the OpenRouter event names.

The same job is also readable at GET /v1/jobs/{id}/status and /result, so a client can keep a single job reader for both routes.

What stays on Video Router

Gemini Omni Flash 1.1 exposes its video edit mode through the Video Router video_url field. The edit source cannot be combined with image_url, end_image_url or reference_*_urls. If your pipeline edits existing footage with that model, leave that call on the legacy route and migrate the rest. The docs do not describe an edit field on /v1/videos.

A safe migration order

Run both routes in parallel for a day on a development key, and compare usage.cost for the same request on each. The docs state both bill at provider list times 1.25.

• Switch read paths first: poll through GET /v1/jobs/{id}/status for jobs created by either route.
• Move text-to-video submits, which need only model, prompt and the shared parameters.
• Move image-to-video and reference-to-video next, after adding frame_type and checking supported_input_references.
• Keep Idempotency-Key on every paid submit throughout the cutover.

Testing the cutover

Pick three requests that cover your traffic: one text-to-video, one image-to-video with a first frame, and one reference-to-video. Submit each on both routes with a development key and compare the polled result, the usage.cost and the final file. Because the model ids are shared and both routes create the same jobs, the outputs should be the same kind of file.

Then switch your reader. A job created on either route can be read through GET /v1/jobs/{id}/status, so you can move submits first and readers second, or the other way round, without a flag day.