Rate limits

The API caps requests per API key per minute. Every response includes the current state in headers, even when you're well under the limit.

Caps

Plan	Requests / minute
Basic	60
Standard	300
Plus	1000

Caps reset every wall-clock minute (00–59 seconds in UTC).

Headers

Every response carries:

X-RateLimit-Limit: 300
X-RateLimit-Remaining: 287
X-RateLimit-Reset: 1715520600

X-RateLimit-Reset is a Unix timestamp (seconds) — divide by 1000 if your client expects ms.

When you hit the limit

You'll get a 429:

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

{
  "error": {
    "code": "rate_limited",
    "message": "Rate limit of 300 requests/minute exceeded. Retry after 47s."
  }
}

The Retry-After header tells you how many seconds until the next window. Honor it — back off and retry. Don't burst.

Strategies

• List endpoints are usually the cheapest way to gather data — pull a list once, then fetch details only when needed.
• Webhooks beat polling for almost every use case. See Webhooks.
• Idempotency keys let you retry any failed POST safely — the second request hits cache instead of doing the work again.
• Cursor pagination avoids over-fetching — pass meta.next_cursor rather than re-listing from page 0.

Per-key, not per-user

Caps apply to each API key independently. If you need higher overall throughput, generate multiple keys — though if you're hitting the cap a lot, tell us what you're building and we can usually help.