Rate limits

• ip — per source IP (behind the ingress; respects X-Forwarded-For set by the trusted load balancer). Cheap edge defence that applies to anonymous and authenticated traffic alike.
• wallet — per your key’s associatedWallet (single_wallet partners) or per the X-User-Wallet header value (multi_wallet partners). Prevents a single wallet identity from exceeding the platform’s per-user ceiling regardless of how the calls are distributed across your keys.

​

Limits

​

Trading (writes)

​

Order reads

​

Market data

​

Portfolio (/me/*)

​

Discovery

​

Counter behaviour

​

Response headers

X-RateLimit-Limit: 100
X-RateLimit-Remaining: 87
X-RateLimit-Reset: 60

• X-RateLimit-Reset is delta-seconds until the bucket refills — i.e. the value 60 means “wait 60 seconds and the limit resets”. This deliberately matches Retry-After semantics; both are seconds-until-refill, not Unix epoch.
• The HTTP header Retry-After is set to the same delta-seconds on every 429.
• On 429 Too Many Requests, the response body uses the standard error envelope:

{
  "status": "error",
  "error": {
    "code": "rate_limited",
    "message": "place-order budget exhausted",
    "trace_id": "..."
  }
}

​

Retry guidance

1. On 429: wait Retry-After (header value, in seconds) before retrying. Do not retry sooner — the bucket has not refilled.
2. Backoff on 5xx: exponential backoff with jitter, starting at 200ms, capped at 10s. Maximum 3 attempts for idempotent calls (GET, DELETE). Do not retry non-idempotent writes (POST /orders, POST /withdrawals/request) automatically — they accept a clientOrderId / nonce for deduplication if your design requires retries.
3. Circuit-break on persistent 5xx: if your error rate exceeds 50% over 30 seconds, stop sending new requests for 60 seconds.

​

Higher limits

• wallet-scoped ceilings can be lifted 10–50× on the place / cancel endpoints.
• ip-scoped limits are lifted on a per-whitelisted-IP basis.
• Platform-wide ceilings cannot be exceeded; they protect the shared matcher.