instanceof checks to handle specific cases.
Error hierarchy
| Class | HTTP Status | When it’s thrown |
|---|---|---|
AirstoreError | — | Base class for all SDK errors. Also thrown for configuration issues (missing API key) and client-side problems (cancelled request). |
APIError | varies | Base class for all API errors. Includes status, headers, and requestId. |
AuthenticationError | 401 | Invalid or missing API key. |
PermissionDeniedError | 403 | Token doesn’t have permission for this operation. |
NotFoundError | 404 | Resource doesn’t exist, or token doesn’t have access to it. |
ConflictError | 409 | Conflicting operation (e.g., duplicate name). |
UnprocessableEntityError | 422 | Request validation failed. |
RateLimitError | 429 | Too many requests. The client auto-retries these. |
InternalServerError | 5xx | Server error. The client auto-retries these. |
APIConnectionError | — | Network-level failure (DNS, TCP, TLS). |
APIConnectionTimeoutError | — | Request timed out. |
Error properties
AllAPIError subclasses include:
| Property | Type | Description |
|---|---|---|
status | number | HTTP status code |
message | string | Error message from the API |
headers | Headers | Response headers |
requestId | string | undefined | x-request-id header value, useful for support requests |
Retry behavior
The client automatically retries requests that fail with these status codes:408, 409, 429, 500, 502, 503, 504.
Retries use exponential backoff starting at 500ms, capped at 8 seconds, with random jitter. If the server sends a Retry-After header, the client respects that timing instead.
By default, the client retries up to 2 times (3 total attempts). You can configure this:
Handling specific errors
Cancellation
Pass anAbortSignal to cancel a request: