Rate limits

Every key carries its own request limit — 10 requests per minute by default, counted per clock minute. The limit is per-key configuration on our side: if your integration legitimately needs more headroom, ask your account contact; it's a setting change, not a code change.

For a typical sync (pages of 100 loads, polling twice a day), the default limit is far more than you'll ever touch.

Response headersCopy Anchor Link

Every authenticated response includes:

When you exceed the limitCopy Anchor Link

The API returns 429 with a Retry-After header (seconds):

HTTP/1.1 429 Too Many Requests
Retry-After: 22
X-RateLimit-Limit: 10
X-RateLimit-Remaining: 0

{"error": "Rate limit exceeded"}

Wait Retry-After seconds and resume. Two details worth knowing:

• Refused requests don't consume quota. A burst of 429s doesn't dig you deeper into the hole; the window drains on schedule.
• The window is a clock minute, and resets on the boundary rather than draining gradually. X-RateLimit-Reset is the exact instant your full allowance returns, and Retry-After is the number of seconds until then — either is safe to wait on.
• A consequence worth designing around: because each minute starts fresh, a burst spanning a boundary can send up to twice your cap in a very short span (10 at 12:00:59, 10 more at 12:01:00) without being refused. Pace against X-RateLimit-Remaining rather than assuming a smooth rate.

If you page through large result sets, a simple if remaining == 0: sleep until reset check between page fetches is all the client-side throttling you need.