Skip to main content
uses one JSON shape for API errors: For the failures relevant to each exact endpoint, use the API error matrix. For request context, pagination, retries and safe updates, use Using the API.
error.code is the stable HTTP category, such as bad_request, unauthorized or forbidden. error.message contains the specific reason, such as not_authorized. error.details may contain validation details. Keep requestId when contacting support.

HTTP status guide

SDK errors

The SDK throws AirctrlError for API failures.

CLI errors

The CLI prints stable error codes instead of raw server or filesystem messages. A non-zero exit status means the command did not complete.
Do not parse human-facing prose from terminal output. Use the command exit status and the stable code written to stderr.

MCP errors

tools return an MCP error result. Your agent can read the safe code and explanation, but it must not keep retrying permission, validation, or missing-resource errors without changing the request.

Authentication and access reasons

The values in this section appear in error.message. The SDK exposes the HTTP category through AirctrlError.code and the specific reason through AirctrlError.message.

Resource and validation reasons

Gateway and provider reasons

Request and service reasons

Validation example

Show validation details to a developer, but do not expose raw internal exceptions or secret values in logs.

Safe retries

accepts Idempotency-Key on writes. Use one UUID for one intended action. A retry with the same key and the same body reuses the first result. Reusing the key with different input returns 409. The SDK creates an idempotency key for writes. For record creation, pass a stable idempotencyKey when your own job may restart and call the method again. Retry only temporary failures such as 429, 500, and 503. Use exponential backoff with jitter and a maximum attempt count.