Rate limits

Limits exist to protect platform stability. Most integrations never hit them.

Default limits

Higher limits are available on request. Reach out to your licensee with your projected volume; they can adjust quotas on their instance.

Response headers

Every response includes rate-limit headers:

X-RateLimit-Limit: 600
X-RateLimit-Remaining: 482
X-RateLimit-Reset: 1715534400

• X-RateLimit-Limit — the cap for this endpoint group
• X-RateLimit-Remaining — requests left in the current window
• X-RateLimit-Reset — Unix timestamp when the window resets

When you hit the limit

Requests over the limit return 429 Too Many Requests with a Retry-After header indicating how many seconds to wait.

// HTTP 429 Too Many Requests
Retry-After: 23

{
  "error": {
    "code": "rate_limit_exceeded",
    "message": "Rate limit exceeded. Retry after 23 seconds."
  }
}

Best practices

• Cache where you can — reference data (statuses, service levels) is static. Cache locally.
• Use webhooks instead of polling — never poll an order for status changes. Subscribe to order_status_changed.
• Implement exponential backoff — on 429, wait Retry-After seconds, then retry with jitter
• Batch when possible — list endpoints accept query filters; use them instead of N individual GETs