Overview

Every error has the same three-field body, so one handler covers all of them:
There is no numeric error code and no errors[] array. No code, no status in the body, no per-field validation list. If you need to branch on a specific failure, match on message for the category and the HTTP status, and log detail for a human.Do not parse detail programmatically. It is prose from the platform and its wording is not a contract.

Status codes

422 is the one that matters

Most real-world failures are 422. The request was well-formed and authorised; the compute platform declined it. Common 422 reasons, with the detail you will see:
422 also covers a wrapped refusal from deep inside the platform. The API walks the whole cause chain looking for a platform rejection, so a nested refusal still surfaces as 422 rather than degrading to a 500. A 500 from this API really is a fault worth reporting.

403 is overloaded

403 means “not permitted” and “your region context is wrong” — including a malformed UUID, which would more naturally be a 400.
Do not treat 403 as permanently forbidden and stop. Here it is frequently a fixable client-side problem. Read detail and act on it — see Regions.

Handling errors

Log all three fields plus the request path. message alone is too coarse to debug from, and detail alone loses the category.

Retry policy

Before retrying any mutation, check whether the original actually succeeded. There are no idempotency keys, so a blind retry can create a duplicate resource. See Asynchronous work.

Asynchronous work

Reading a failed job, and retrying safely.

Regions

Why so many 403s are region problems.

Quotas and limits

The usual cause of a quota 422.

Conventions

Timestamps and content types.