Skip to main content
Every SDK raises the same error taxonomy with the same fields, so error handling you write once behaves identically in TypeScript, Swift, and Kotlin.

The error shape

Branch on code, never on message. The code value is part of the API contract and is stable across versions; message is for humans and can change.

Status to error kind

Each SDK maps the HTTP status to an idiomatic typed error (a subclass in TypeScript/Swift, a sealed type in Kotlin) so you can catch exactly what you mean. Beyond HTTP, the SDKs also surface transport-level kinds that never reached the server: network, timeout, decoding, and notConfigured.

Handling errors

Stable codes worth handling

These code values are stable and worth branching on explicitly:

Using the request id

When something goes wrong in production, log requestId. It is the X-Request-Id header on the response and lets support trace the exact call in the server logs. Every response carries one, success or failure.
Retryable failures (429 and 5xx) are retried automatically by the SDK with full-jitter backoff. See Retries and idempotency.