Skip to main content
The SOAX API uses conventional HTTP status codes. Anything in the 2xx range is success, 4xx means something is wrong with the request, and 5xx means something went wrong on the SOAX side.

Error response shapes

Errors return a JSON object with the message under one of two keys, depending on which validation layer rejected the request. Endpoint-level checks (auth, scopes, not-found, pagination and count limits) use detail:
Deeper business-rule validation — connection-string rule combinations, analytics date ranges and filters, API key creation rules — and all 429s use error:
The split is an implementation detail you shouldn’t depend on — in your error handling, read detail ?? error and treat them the same. The tables below show which key each message actually uses. 422 validation errors (a parameter or body field failed type/format validation) are the third shape: a detail array, one entry per problem, with the location of the offending field:

Status codes

Every response includes an x-request-id header. Log it — support can trace exactly what happened to a request from that ID.

Common error messages

Messages under the detail key: Messages under the error key:

Handling errors in code

A pattern that covers the cases worth automating — retry 429 and 5xx, surface everything else:
These are errors from the API (api.platform.soax.com). Errors from the proxy gateway (proxy.soax.com:1337, e.g. 407 AUTH_FAILED) are a different system with different codes — see Proxy error codes.