ApiError. There is exactly one shape, and it is a transcription of the server’s error envelope — the client adds no taxonomy of its own, so the two can never disagree.
The ApiError class
number
The HTTP status, e.g.
404.string
The error family from the envelope, e.g.
not_found, invalid_request.string
The specific machine code, e.g.
validation_failed, subscription_required, insufficient_credits.string | undefined
The offending field, when the server names one. This is what the CLI prints.
string
The server’s correlation id for this call — quote it in a bug report; it is the single most useful field.
string
The human-readable message from the envelope.
Catching
What the client does not do
- No retries. A caller that wants retries owns that decision — the CLI and the dashboard want different policies. A
429or5xxis thrown like any other error. - No code → status table.
typeandstatusare read off the response. The server owns that mapping; a second copy here would be a second taxonomy that could drift.
Errors worth planning for
The full catalogue lives in the API error reference.