Which Sume API errors should page an engineer: route by category

Route Sume API failures by category: fix-the-input errors go to the caller, quota to finance, queue to a retry, and only internal or unexpected 5xx to on-call.

5 min readSume
All posts

Most Sume API errors are not incidents. The error envelope carries code, category, retryable, retry_after_seconds and next_action, so your handler can decide who should hear about a failure without parsing messages. Page on-call only for what a human on the engineering side must fix.

A routing table

The categories below come from the Sume docs' list of job error categories; the owner column is a recommendation, not Sume behavior.

Sume error category to owner (read 2026-10-03)
CategoryTypical next actionSuggested owner
validationFix inputCaller or product team
authCheck API key and workspace accessPlatform team, ticket
quotaAdd funds or lower request costFinance or spend owner
queueRetry later with the same idempotency keyAutomatic retry, alert on sustained
generation_unavailableRetry laterAutomatic retry
generation_rejectedInspect events, fix unsupported inputProduct team
runtime_unavailableRetry later, not aggressivelyAutomatic retry, watch rate
internalInspect events, contact support with request idOn-call

Branch on code, then status

Branch on the HTTP status first, then on code; the message is for humans and may change. A 4xx at create means nothing ran and nothing was charged, so retrying it in a loop is the expensive mistake, with a 403 insufficient_scope loop as the classic example.

Always keep the request id

Every error body includes a request id, also sent as x-sume-request-id, safe to share with support. Put it in the ticket or alert text so nobody has to reproduce the call.

Sources

Related posts

More in Developers

All Developers posts

Written by Sume