frame_images or image_url? Image-to-video fields on Sume's two APIs
Sume's /v1/videos uses frame_images and input_references; /v1/video-router/generate uses image_url, end_image_url and reference_*_urls. A field-by-field map.

On POST /v1/videos you pass images as frame_images (first or last frame) and input_references (style or content). On POST /v1/video-router/generate the same jobs use flat fields: image_url, end_image_url and reference_image_urls. Both paths create the same jobs with the same model ids, so a migration is a path-and-body change.
Field map
The Sume docs recommend /v1/videos for new integrations and keep the Video Router unchanged. Responses differ in envelope: Video Router returns Sume's { "data": ... } job envelope, and /v1/videos returns the OpenRouter-style shape with polling_url and unsigned_urls.
| Intent | POST /v1/videos | POST /v1/video-router/generate |
|---|---|---|
| First frame | frame_images[] with frame_type first_frame | image_url |
| Last frame | frame_images[] with frame_type last_frame | end_image_url |
| Reference images | input_references[] type image_url | reference_image_urls |
| Reference video | input_references[] type video_url | reference_video_urls |
| Reference audio | input_references[] type audio_url | reference_audio_urls |
| Edit source (Omni) | video_url via the Video Router | video_url |
| Retry safety | Idempotency-Key header | Idempotency-Key header |
What happens when you mix modes
On /v1/videos, if a request has both frame_images and input_references, frame_images controls the mode and Sume processes it as image-to-video. A model accepts a reference type only if its supported_input_references lists it. Seedance 2.x, Wan 3.0, MiniMax H3 and H3 Max accept audio and video references; Gemini Omni Flash 1.1 accepts image and video references but not audio.
Not every row mixes modes. The catalog marks Omni as treating a lone reference image with no first or end frame as reference-to-video, and keeps video_url edit requests exclusive of every image field.
- Read
supported_frame_imagesandsupported_input_referencesfromGET /v1/videos/modelsbefore you build a request. - Image URLs must be public HTTPS and in supported formats.
- Send
Idempotency-Keyon every retryable submit.
A minimal migration
To move a Video Router first-frame body to the newer endpoint, wrap image_url as a frame_images entry:
{
"model": "wan-3.0",
"prompt": "A paper boat drifts down a rain gutter",
"duration": 5,
"frame_images": [
{
"type": "image_url",
"image_url": {"url": "https://example.com/boat.png"},
"frame_type": "first_frame"
}
]
}Which wire to pick
New integrations should use /v1/videos: it is the OpenRouter-compatible shape, it accepts sume/auto, and it reports jobs through polling_url. Existing Video Router callers do not have to migrate; Sume says that API stays available and does not change.
Either way, the same job is visible at GET /v1/jobs/{id}/status and GET /v1/jobs/{id}/result, so one status poller can watch jobs created by both.
Sources
Related posts
More in Developers
- gemini-3.1-flash-image deprecated: Nano Banana 2.1 on Sume
Google deprecated gemini-3.1-flash-image on Oct 6 when Nano Banana 2.1 went GA. Which ids Sume accepts, what it bills per image, and what Google lists.
- Gemini 3.7 Flash now routes to 3.8: where a media client pins ids
Google auto-routes gemini-3.7-flash to gemini-3.8-flash since Oct 8. Where Sume lets you pin a model, where it routes for you, and what the job records.
- Gemini Omni Flash 1.1 prompt length on Sume: a 20,000-character check
The Sume catalog constraint for Gemini Omni Flash 1.1 is a prompt of at most 20,000 characters, 3 to 10 seconds. A short Python preflight check before you pay.
- Omni Flash defaults to 720p and 16:9: set both on every request
Google's Omni docs default to 720p and 16:9; Sume's Auto defaults to 720p and 8 seconds. Why to send resolution, ratio and duration every time, with prices.
Written by Sume