Sume GET /result returns 409 job_not_completed: poll status first

GET /v1/jobs/{id}/result answers 409 job_not_completed while a Sume job is queued or processing, and for failed or canceled jobs too. It never returns an empty result. Poll GET /v1/jobs/{id}/status until result_ready is true, then fetch. Read a failure from the job record, not from the result route.

Why a 409 and not an empty body

A result is defined only for completed jobs. An empty successful response would look like a finished job with no output, which is worse than a clear refusal. The 409 is retryable in the one case that matters: the job is still running, so waiting and asking again is correct. For a terminal failure it is not retryable, because no result will ever exist.

On /v1/videos

The video route has two distinct 409 codes. job_not_completed on the content route means the job is still running and is retryable. job_failed means the job reached a terminal failure and is not retryable. Branch on the code, not on the status number alone.

The sequence in curl

Submit async, store the id, poll status, fetch once.

curl -X POST https://api.sume.com/v1/image-1.0/generate \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: hero-001" \
  -d '{"prompt":"matte black bottle on marble","mode":"async"}'

curl https://api.sume.com/v1/jobs/job_123/status \
  -H "Authorization: Bearer $SUME_API_KEY"
# when "result_ready": true
curl https://api.sume.com/v1/jobs/job_123/result \
  -H "Authorization: Bearer $SUME_API_KEY"

A common mistake

Calling result right after submit and treating the 409 as an outage leads to resubmits, and each resubmit without a stored job id is a new paid job. Keep the id from the first response, poll, and fetch once. A 409 here is a prompt to wait.