Skip to main content
Every error is JSON and is never sealed, so a 4xx or 5xx is always readable:
  • code is one of the codes below. The set is closed and every code starts with ENSC_, so it is greppable in your logs.
  • message is human-readable and may change; branch on code, not on message.
  • requestId (also in the X-ENSC-Request-Id header) identifies the exact request. Quote it when contacting support.
  • details is optional structured data, for example maxAmountIn on ENSC_RESERVE_INSUFFICIENT, retryAfterSeconds on ENSC_KYT_HOLD or retriable on ENSC_SETTLEMENT_VERIFICATION_FAILED.

In the SDK

Every failure, including network errors, throws a single EnscError type with the same code taxonomy the API uses. Every EnscError carries status (the HTTP status received, so a code added by the API later still classifies correctly) and requestId (from the error body or X-ENSC-Request-Id; quote it to support), plus details where the API sent them.
The SDK retries only network errors, timeouts and the statuses 500, 502, 503 and 504 (maxRetries, default 2), with a stable idempotency key; it never retries a 4xx, including 429.

Codes the SDK raises itself

Request, authentication and authorization

Encryption

Chains, assets and amounts

Conversions

Transaction screening

Bank rail

ENSC-side failures (5xx)

The SDK retries 500, 502, 503 and 504 automatically; if one persists, quote the requestId to support.