2026-10-03

Sume hides provider names and task ids: what to debug with

Sume job responses and events are provider-neutral: no vendor task ids or raw URLs. The fields to debug a video job with instead.

5 min readSume

All posts

Developers coming from a model vendor often look for the vendor's task id when a render stalls. On Sume there is none to find. The admission page states that public API responses are provider-neutral and do not expose hidden provider names, raw provider task ids, raw provider URLs, internal workflow names, storage object keys, API keys, or private workspace and user metadata. The jobs page adds that public events do not expose raw provider task ids or URLs.

That is a design choice, and it changes how you debug a video job: use the fields Sume gives you, and send the request id and job id when you need a person.

What you can read instead

These come from the jobs and error pages, read on 2026-10-03.

Debug fields on a Sume video job (read 2026-10-03)
Where	Field or event	Tells you
GET /v1/jobs/{id}/status	status, terminal, result_ready, next_poll_after_seconds	Where the job is and when to look again
GET /v1/jobs/{id}/events	job.created, job.queued, job.started, generation.submitted, job.completed, job.failed, job.canceled, webhook.delivery	A public timeline
Failed job error	category, stage, retryability, retry-after seconds, public reason, next action	Whether to fix, wait or retry
Error body	request_id	The identifier support needs

Reading the timeline

A job that sat in queued for a long time and then started is a capacity story: look at queue counts and your plan. A job with generation.submitted and no terminal event is still with the model. A job with job.failed has an error object; read the category, because validation means fix the input and generation_rejected means inspect the events and fix unsupported input. A job that completed with no webhook has a webhook.delivery event to explain why.

None of this needs a vendor id, which is why the API does not expose one.

Retries and billing during a failure

Failed jobs release or refund the reservation where applicable. To retry, resubmit with the same Idempotency-Key if the first attempt never produced a job, or with a new key when you have changed the request. Do not resubmit just because a worker of yours timed out; the original job may still be running and billing.

What to keep out of logs

Log job id, request id, model id and your own timestamps. Do not log API keys, signed or raw media URLs, or private workspace and user ids. Those are the same values the error docs say not to share.

A debugging order that works

Start with the status: is the job queued, processing or terminal? Then read the events. Then, for a failure, read the error category and next action. Only then write to support, with the job id and request id. Most stalls end at the second step because the timeline shows whether the job ever started.

Keep your own copy of that timeline for jobs that matter. The events endpoint is a pull snapshot, so a record you saved at the time is easier to compare across runs than one you reconstruct later.

Limits

The docs do not describe how Sume maps its public error categories to underlying provider failures, so a category is the finest detail you will get. If it is not enough for a decision, send the request id to support.