Skip to main content
The ZLL Trading API reports failures two ways, and you handle both. A non-2xx status carries an application/problem+json (RFC 9457) body; branch on its code member. A 200 OK can still report a rejection in its body; never treat 200 as success on its own.

​
Trust the HTTP status line

The HTTP status line is authoritative. A 2xx means the request reached the exchange and was processed; a non-2xx means it was rejected before processing completed. The error body repeats the status, but the status line is what you act on. For the full list of status codes and their retry semantics, see Error codes.

​
ProblemDetails (RFC 9457)

Every non-2xx response carries media type application/problem+json and the body below. All five members are always present.
​
type
string
required
URI reference identifying the problem type. about:blank when none is defined.
​
title
string
required
Short, human-readable summary of the problem type (the HTTP status phrase).
​
status
integer
required
HTTP status code, duplicated into the body for convenience. Advisory — when it disagrees with the response status line, trust the status line.
​
detail
string
required
Human-readable explanation specific to this occurrence. May change; do not branch on it.
​
code
string
required
Stable, machine-readable error code for programmatic handling (for example rate_limited). Branch on this.
{
  "type": "about:blank",
  "title": "Bad Request",
  "status": 400,
  "detail": "request_id timestamp is outside the accepted window",
  "code": "request_timestamp_skew"
}

​
A 200 can still be a rejection

A 200 OK means the request was processed, not that it was accepted. Signed-write endpoints and account/key/session endpoints both return 200 even when the exchange rejects the request on its merits. Read the body to confirm the outcome — a 200 with a rejection in the body is normal.
Accepted and rejected signed writes both return a RequestAck body:
{ "status": "request_completed", "processed_at_ns": 1719158400000000000 }
  • status — the outcome. request_completed means accepted. Any other value (a rejected_* status, order_rejected_*, insufficient_margin_to_place, and so on) is a rejection.
  • processed_at_ns — the exchange processing time, in nanoseconds since the Unix epoch.
Branch on status on every response. The full status enum is in Error codes.

​
Handling order

Apply both layers, in order:
1

Check the HTTP status line

Non-2xx is a transport error. Parse the application/problem+json body and branch on code. See Rate limits for 429 and 413.
2

On a 200, read the body

Inspect status (signed writes) or success (account/key/session writes). Treat anything other than request_completed / success: true as a rejection.