stream: true on Sume's Images API returns 400: use async and events
Sume's image catalog rows report supports_streaming false, so stream: true is a 400 streaming_not_supported. Submit async and read /v1/jobs/:id/events instead.

stream: true on POST /v1/images returns 400 streaming_not_supported. Every catalog row reports supports_streaming: false today, because native SSE streaming of partial images is not served in v1. The field exists in the schema so that clients can adopt streaming later without a code change.
For progress, submit with mode: "async" and read GET /v1/jobs/{id}/events, or use a webhook for the terminal event.
Four modes, one useful for progress
| Mode | What you get | Progress? |
|---|---|---|
| sync (route default) | Waits up to wait_timeout_seconds (0 to 30, default 30), then 200 with images or 202 with the job | No |
| subscribe | An alias of sync: one bounded wait of up to 30 seconds | No |
| async | 202 with status_url, result_url and events_url at once | Yes, via the events URL |
| webhook | 202, then a signed callback on job.completed, job.failed or job.canceled | Terminal only |
Do not confuse subscribe with streaming
The name suggests a stream. The jobs doc says mode: "subscribe" is not a progress stream; it behaves like sync. If you want a live bar in the UI, async plus events is the supported path, and polling status_url until terminal is true is the fallback that always works.
Gate the UI on the catalog
Read supports_streaming from GET /v1/images/models instead of hard-coding it. When Sume ships streaming for a model, the flag changes and your code starts to use it. Until then, show a spinner and the job state.
- Do not send
stream: trueand catch the 400 as flow control. - Keep the wait short for a UI (a few seconds), then fall back to the
202job. - Use the same
Idempotency-Keywhen you retry the submit, so you do not pay for a second job.
A minimal async-and-poll loop
A progress UI needs three things: the job id from the 202 envelope, a poll interval of a second or two, and a stop on terminal. Show elapsed time to the user rather than a fake percentage, because the job reports states and not progress.
Failed and cancelled generations are not billed. If the user closes the tab, the job can still finish, so store the job id and resume the poll when they come back. A webhook is the better fit for server-side flows where nobody is watching: you get one signed callback per terminal state and can keep polling as a backup.
What a progress poll looks like
Submit async, take status_url from the envelope, and poll the booleans terminal and result_ready. Read the images from result_url when result_ready is true. The Jobs and results page has the field list, and Webhooks covers signature checks for the terminal callback.
Sources
Related posts
More in Developers
- STT 1.0 or video inspect transcribe: two ways to transcribe on Sume
Both bill about $0.01 per audio minute on Sume, but STT takes an audio URL and video inspect takes a Sume clip. Limits of 10 minutes and 1,800 seconds.
- Submit 12 thumbnail jobs with mode async and Idempotency-Key on Sume
Queue a dozen 16:9 thumbnails on POST /v1/images with mode async and one Idempotency-Key each. Re-run the script safely, then poll the status URLs. Python code.
- Submit 40 image jobs with mode webhook in Python on Sume
Send 40 POST /v1/images calls with mode webhook and a webhook_url: each returns a 202 job envelope at once and the result follows. Python, cost, status codes.
- Submit 6 ad hooks in parallel in Python with one Idempotency-Key each
A Python script that submits six 3-second Omni hook jobs in parallel, each with its own Idempotency-Key so a retry replays the original job. Cost: $2.25.
Written by Sume