API reference

Errors & status codes

Responses use standard HTTP status codes. Errors carry a JSON body describing what was rejected.

200The request succeeded and the resource is in the response body.

201The resource was created and is returned in the response body.

202The request was accepted and is being processed.

204The request succeeded. There is no response body.

400The request was malformed or violated a constraint described on the endpoint.

401No valid access token was supplied, or it has expired.

403The token does not carry the scope required for this resource.

404The resource does not exist, or is not visible to your organisation.

409The request conflicts with the current state of the resource, for example a market gate that has already closed.

422The request could not be processed. The response body names the fields that failed validation.

429Too many requests. The rate limit is 600 requests per minute per organisation; retry after the interval in the Retry-After header.

500An unexpected error on our side. The response carries a request_id — quote it when you report the incident.

Every endpoint in the reference lists the codes it can raise, inline under its description.

Error body

Validation failures name every field that was rejected. Other errors carry a machine-readable code, a human-readable message and a request_id to quote when you report the incident.

Validation error422

{
  "detail": [
    {
      "loc": ["body", "start_time"],
      "msg": "field required",
      "type": "missing"
    }
  ]
}

Retries & rate limits

Rate limit: 600 req / min per organisation
Safe to retry: 429 and 500, with exponential backoff. GET is idempotent; PUT and DELETE are idempotent by design.
Do not retry: 400, 403, 404 and 422, the request has to change first. 409 usually means a market gate closed; the next window is the fix, not a retry.