Rate limits

Limits are per API key. The default tier is 60 requests per minute; higher-volume partners can be moved to a higher tier — ask us.

Every response carries the current budget:

Header	Meaning
X-RateLimit-Limit	Your ceiling for the window
X-RateLimit-Remaining	Requests left in the window
X-RateLimit-Reset	Seconds until the window resets

There's also a coarse per-IP ceiling in front of authentication (a brute-force backstop). Legitimate server-to-server traffic won't hit it; it exists so a flood of bad keys can't hammer the auth layer. It, too, returns 429 rate_limited.

When you go over either limit, you get 429 rate_limited with a Retry-After header. Wait that long, then retry — ideally with exponential backoff and jitter so a burst doesn't all retry at once.

{ "error": { "code": "rate_limited", "message": "Rate limit exceeded", "request_id": "req_…" } }

Staying under

• Quote once and reuse it for the few seconds it's valid, rather than re-quoting in a tight loop.
• Prefer webhooks over polling GET /v1/swaps/{id} to learn when a swap settles.
• Spread background reads (history, order lists) out instead of bursting them.

INFO

The limit is enforced per running instance, so during high availability the effective ceiling can be slightly above the configured number. Don't rely on hitting it exactly — treat the limit as a floor you're guaranteed, and back off on 429.