Rate Limits

The API is rate limited, per IntegrationClient, to keep the service healthy for everyone using it. Different routes may have different limits, and limits are an operational policy, not a contractual guarantee - they may change without notice. Build your integration to handle 429 gracefully rather than hardcoding an assumption about a specific number of requests per minute.

When you’re rate limited

{
  "error": {
    "code": "rate_limited",
    "message": "Rate limit exceeded.",
    "details": {},
    "requestId": "req_..."
  }
}

HTTP 429, error.code: "rate_limited", and a Retry-After response header (seconds) telling you how long to wait before your next request is likely to succeed.

How to build for it

• Check Retry-After and wait at least that long before retrying - don’t retry immediately in a tight loop.
• Use exponential backoff for repeated 429s beyond the first, in case load conditions persist longer than one Retry-After window.
• Don’t poll faster than you need to. If you’re syncing data on a schedule, pick an interval that reflects how often the underlying data actually changes, and use updatedSince so a normal sync run is cheap regardless of interval.
• Spread bulk work out. If you need to fetch many pages, don’t fire them all in parallel with no pacing - a sequential loop with modest concurrency is friendlier to shared limits and easier to reason about when something goes wrong.

What’s not published

Specific current numeric limits (requests per minute, per route) are intentionally not published as a fixed guarantee here, since they’re an internal operational lever that may be tuned. Treat 429 + Retry-After as the contract, not a specific number you’ve observed in testing.