Sume API status values: jobs, runs, queues, and webhooks

Sume API generation jobs move through queued, processing, completed, failed, and canceled, Format and Action runs add skipped, and POST /v1/videos spells the same lifecycle pending, in_progress, completed, failed, and cancelled. Bulk queues, webhook deliveries, usage rows, grants, and your balance each have their own values, listed below.

Every value comes from Sume's docs, such as Jobs and results, Runs and results, and Errors and rate limits, or from the live OpenAPI reference, read on 2026-09-27; each table caption names its pages. For how a job differs from a run, see Sume job vs run.

Which statuses do jobs and runs use?

Each row links the post that explains that object in depth.

Which statuses do queues, webhooks, and billing use?

These objects sit around jobs and runs rather than inside them:

Is it canceled or cancelled?

One l everywhere except POST /v1/videos. Jobs, runs, bulk items, and resources spell it canceled; the OpenRouter-shaped video route answers cancelled, and it also says pending for queued and in_progress for processing. Compare strings per surface rather than sharing one enum.

Scheduled runs show why. Their statuses remap internal ones: done surfaces as completed, error as failed, and cancelled as canceled, and the docs warn not to assume job-side status strings transfer.

Which values are terminal, and which send a webhook?

Stop polling a job on completed, failed, or canceled, and a run on those three or skipped. Terminal is not the same as delivered:

• Job webhooks fire on all three terminal statuses, as job.completed, job.failed, and job.canceled.
• Run webhooks fire once, on completed or failed. A canceled or skipped run never delivers, so read the cancel or create response instead.
• A skipped Scheduled run carries skip_reason: previous_run_active; preventing overlapping runs covers when that happens.
• A bulk queue's completed still needs a check of counts.failed and counts.canceled.

What does outcome add to a webhook's status?

A run webhook's status is binary. outcome answers whether you got usable output: ok is completed with output, error is a run that did not complete, and degraded is a completed, billed run whose receipt still carries an output_error. A completed receipt carries one when, for example, output_extraction_failed reports details.reason: harvest_unavailable: the projection could not run, status stays completed, and the receipt fills in on the next read.

Over the API, a result that does not match your output_schema fails the run: status is failed and error carries the same reason as output_error. That run arrives with status: "ERROR" and outcome: "error". Branch on outcome when the question is whether you got usable output.