Sume job error categories and the next action for each
Failed Sume jobs carry a category: validation, auth, quota, queue, generation_unavailable, generation_rejected, timeouts, runtime_unavailable or internal.
Failed Sume jobs expose public error metadata such as category, stage, retryability, retry-after seconds, public reason and next action (read 2026-10-06 in the errors docs).
Which category needs which action?
The docs map each category to a typical next step.
| Category | Typical next action |
|---|---|
| validation | Correct the input |
| auth | Check the API key and workspace access |
| quota | Add funds or reduce cost |
| queue | Retry later with the same key |
| generation_rejected | Check events, fix unsupported input |
| generation_timeout | Poll status or retry later |
| internal | Check events, contact support |
What should I do in practice?
Retry only when the category allows it.
- Branch on category, not message text.
- Respect retry-after seconds.
- Internal provider payloads are not public fields.
Sources
Related posts
More in Developers
- Sume job.canceled and job.failed webhooks both say status ERROR
A Sume job.failed and a job.canceled webhook both carry status ERROR and an error object. Branch on the event name, not on status, to tell them apart.
- Sume job status logs_available is false: read events_url instead
A Sume job status carries logs_available, false while diagnostics live behind events_url. Read the events timeline for the lifecycle, not inline logs.
- Sume job statuses: queued, processing, completed, failed, canceled
The five Sume job statuses and what a client should do at each. Resources use a different set: processing, ready, failed, canceled and archived.
- Sume job webhook events: job.completed, job.failed, job.canceled
Sume sends only terminal job events: job.completed, job.failed and job.canceled. No progress events. Failed and canceled payloads carry status ERROR.
Written by Sume