Sume sync mode returned 202: the 30-second wait is not an error

A 202 from a Sume sync call means the 30-second wait ended, not that generation failed. The response still carries the job id, status_url, result_url and events_url. Keep polling status_url. Do not submit again, because the first job is running and billed. Video usually exceeds the wait; images often fit.

What the cap is

wait_timeout_seconds is clamped to 0 through 30. It limits how long the HTTP request blocks, not how long the job can take. subscribe is an alias of sync and gives the same bounded wait. It is not a progress stream, and the Developer API has no SSE or WebSocket transport.

Read the envelope

In the envelope, sync.timed_out is true when the wait ended before a terminal state. sync.capacity_exhausted is true when Sume skipped the wait because its waiter budget was used. Either way you continue the same way: follow next_poll_after_seconds if present, otherwise back off.

The client loop

This JavaScript polls to a terminal state and then fetches the result.

const h = { Authorization: `Bearer ${process.env.SUME_API_KEY}` };
const base = 'https://api.sume.com/v1/jobs/';

async function wait(id) {
  for (;;) {
    const s = await (await fetch(base + id + '/status', { headers: h })).json();
    if (s.terminal) return s;
    const sec = s.next_poll_after_seconds ?? 5;
    await new Promise((r) => setTimeout(r, sec * 1000));
  }
}

Prefer async for long work

For video, submit with mode: "async" and poll, or use mode: "webhook" and keep the poll as a backup. A client-side timeout does not cancel the job. If you stopped waiting, you still own a running job, so store its id.

Images: 200 or 202

POST /v1/images defaults to sync, so you will see both outcomes. A 200 carries data[].url directly. A 202 is the job envelope, and you read the images from the standard result endpoint once result_ready is true. Code that only handles 200 will break on the first slow image, so handle both from day one.