Reference

Rate limits

Current request limits, the 429 response and Retry-After.

Rate limits protect the platform and every customer on it. The limits below are the ones in force today.

Surface	Limit
Requests with an API key	60 per minute per key
Requests with an API key	180 per minute per business (tenant), shared by all its keys
Public catalog (`GET /catalog`, no key)	120 per minute per IP address

Both the per-key and the per-business limit apply; whichever is reached first blocks the request. GET /me always shows the limits that apply to your key under rate_limits.

Repeated failed authentication attempts are limited separately (per client address and per key prefix), so a script with a wrong key will be slowed down.

Headers

Successful responses include:

X-RateLimit-Limit: 60
X-RateLimit-Remaining: 57

When you are limited

You receive 429 rate_limit_exceeded and a Retry-After header with the number of seconds to wait:

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

{
  "error": {
    "type": "rate_limited",
    "code": "rate_limit_exceeded",
    "message": "Too many requests. Please retry later.",
    "request_id": "req_01example0000000000000000"
  }
}

Good practice

Wait at least Retry-After seconds before retrying; add a little random jitter.
Use limit=100 on list calls and follow next_cursor rather than making many small requests.
Prefer webhooks to polling for changes.
Cache the public catalog; it changes rarely, and responses carry an ETag.