API sync mode wait timeout: the job is still running, so poll
When a Sume sync request returns before the job ends, the job still runs. Read sync.timed_out and sync.capacity_exhausted, then poll status_url, not a resubmit.
A sync wait that runs out is not a failure. On Sume the response is still a 2xx, it still carries the job id, and the job keeps running and billing. Read the sync object on the envelope, then continue with GET status_url instead of submitting the request again.
What does the sync wait actually bound?
wait_timeout_seconds is clamped to 0..30, and it bounds how long the HTTP request blocks, not how long the job may take. Image jobs often finish inside it. Video, avatar-video and face-swap jobs routinely do not, so a returned-but-unfinished response is the normal case for them, not an edge case.
Which field says why the wait ended early?
Two flags on the sync object give the reason. The object is null on async and webhook responses, so only check it when you sent sync.
| Flag | True when | What you do |
|---|---|---|
sync.timed_out | The wait returned before a terminal state. | Poll status_url. |
sync.capacity_exhausted | Sume skipped the wait because the per-process waiter budget was full. | Poll status_url; the job was still accepted. |
What do I do next?
Continue with GET status_url, honoring next_poll_after_seconds when it is present and backing off otherwise. The envelope also carries result_url, events_url and cancel_url. Do not submit a new paid job for the same intent.
Retrying the submit itself is fine, provided you reuse the same Idempotency-Key so the retry returns the original job rather than billing a second one. Details on keys are in idempotency keys for AI video APIs.
Should I use sync mode for video at all?
Only when you can live with the fallback. Because a wait can end early for either reason, every sync caller needs the polling path anyway; async plus polling, or a webhook, is the same code without the blocked request. The docs page for Jobs and results has the full mode table.
What does a client-side timeout do to the job?
Nothing. A client-side timeout does not cancel the job: it keeps running and still bills, and you have only stopped watching. Store the job id from the first response and pick it back up from the status URL, or cancel it explicitly.
That is why the first response always carries the job id, in every mode. A 2xx means the job exists and paid work is in flight; it does not mean the job finished. Read terminal and result_ready off the envelope to tell those apart, instead of treating the status code as the outcome.
If you would rather not handle an unfinished response at all, submit with async and poll, or ask for a webhook and keep status polling as a backup for missed deliveries.
Sources
Related posts
More in Developers
- Talking avatar in JS: make one from Node, play it in React
A talking avatar in JavaScript: create it and send it a script from Node with the Sume SDK, wait for the job, then play the returned MP4 in React.
- Avatar video quality settings: standard, plus or max?
Sume's talking avatar video takes quality standard, plus (default) or max. What each means, the other output fields, and how the preview relates to final tier.
- AI avatar video length limit: 4 to 60 seconds per job
Sume's avatar video accepts an estimated 4 to 60 seconds per job, for scripts, scenes, previews and inline captions. Where it applies and what to do outside it.
- Talking photo AI without watermark: what Sume documents
Sume's docs describe no watermark option for talking photo clips. They do fix the inputs: a still, Sume-hosted audio under 10 MB, 1-300 s or 5-14.8 s by route.
Written by Sume