Rate limits

Requests are rate limited per API key to keep the platform fast and fair.

The default limit is 60 requests per minute per API key. When you exceed it, responses include a Retry-After header (in seconds). Higher limits can be arranged with your account manager - always design your integration to respect 429 responses.

Response headers

Every v2 response includes rate-limit headers:

Header	Meaning
`X-RateLimit-Limit`	Maximum requests allowed in the current window
`X-RateLimit-Remaining`	Requests remaining in the current window
`X-RateLimit-Reset`	Unix timestamp (seconds) when the window resets
`Retry-After`	Present on `429` only - seconds to wait before retrying

Use X-RateLimit-Remaining to slow down proactively before hitting the limit.

When you exceed a limit

You receive 429 Too Many Requests:

{
  "statusCode": 429,
  "error": "Too Many Requests",
  "message": "Rate limit exceeded. Retry after 30s."
}

Best practices

Back off

On 429, wait for Retry-After (or read X-RateLimit-Reset) before retrying.

Poll sensibly

Poll orders at or after estimatedReadyAt, then about once a minute - not in a tight loop.

Batch reads

Use take=100 and filters to reduce the number of calls.

Cache the catalog

The catalog changes infrequently - cache it and refresh periodically.

Idempotency Errors

Get started

Core concepts

Migrate

Response headers

When you exceed a limit

Best practices

Back off

Poll sensibly

Batch reads

Cache the catalog

​Response headers

​When you exceed a limit

​Best practices

Back off

Poll sensibly

Batch reads

Cache the catalog

Response headers

When you exceed a limit

Best practices