2026-10-03

Sume video sync submit: timed_out and capacity_exhausted flags

A sync submit returns 2xx with a job id even when the wait runs out. What the sync object says and what to do next.

5 min readSume

A sync submit on a Sume generation endpoint blocks for at most 30 seconds and returns the same job envelope either way. When the wait ends before the job does, the response is still 2xx, still carries the job id, and carries a sync object. sync.timed_out is true when the wait returned before a terminal state. sync.capacity_exhausted is true when Sume skipped the wait because the per-process waiter budget was full. Both mean the same thing for you: the job exists, paid work is in flight, and you must keep polling.

Video jobs routinely take longer than 30 seconds, so these flags are the normal case for video, not an edge case.

Reading the envelope

From the jobs page, read 2026-10-03.

Fields to read on a sync submit response (read 2026-10-03)
Field	Meaning	Next step
job id	The job exists in every mode	Store it first
terminal	Whether the job finished	If true, read the result
result_ready	Whether the result can be fetched	If true, GET result_url
sync.timed_out	Wait returned before a terminal state	GET status_url and keep polling
sync.capacity_exhausted	Wait skipped because waiter capacity was full	Same as above

What you must do and must not do

You must continue with GET status_url, honoring next_poll_after_seconds when it is present and backing off otherwise. You must not submit a new paid job for the same intent. Retrying the submit itself is fine if you reuse the same Idempotency-Key, because the retry returns the original job instead of billing a second one.

The wait budget is a bound on the HTTP request, not on the job. wait_timeout_seconds is clamped to 0 through 30. For video, async with polling or webhook is the better default, and the docs say sync is the wrong tool for anything that can outlast 30 seconds.

subscribe is not a stream

The subscribe mode is an alias of sync. It is one bounded HTTP wait, not an event stream, and there is no SSE or WebSocket transport on the Developer API. For progress, submit async and read GET /v1/jobs/{id}/events, a pull snapshot, or take a webhook. The sync object is null on async and webhook responses.

A defensive client

This client treats a timed out wait as a handoff to polling and never as a failure.

After any submit, store the job id before reading anything else.
If terminal is true, read the job from the response and stop.
Otherwise poll status with backoff until terminal is true.
Fetch the result only when result_ready is true; otherwise /result answers 409 job_not_completed.

Choosing a mode for video

For video, start with async and poll, or use a webhook and keep polling as a backup. Use sync only for a short job where a 30 second wait is acceptable and you can handle the timeout flags. The jobs page lays out four modes in a table: async returns 202 with polling URLs, sync and subscribe wait, and webhook stores a callback.

Sending callback_url without a mode selects webhook delivery, so the intent is clear from the request. In every mode, the job id is in the first response.

Limits

The docs do not give the per-process waiter budget, so you cannot predict capacity_exhausted. Write your client so that every response may carry either flag.