reference

Rate limits

/v1 is rate-limited per API key with a token-bucket limiter. Each key gets its own independent bucket, so one key hitting its limit never throttles another key — including other keys on your own account.

How the bucket works

  • The bucket holds up to a burst of tokens and refills at a steady sustained rate (tokens per second).
  • Each request spends one token. If a token is available, the request proceeds.
  • If the bucket is empty, the request is rejected with 429 rate_limited and a Retry-After header (in seconds) telling you how long until a token refills.

This means you can burst up to the bucket size after an idle period, then settle into the sustained rate. In the dev preview the default is a burst on the order of a minute's worth of sustained calls; treat the exact numbers as subject to change and drive your client off the Retry-After header, not a hardcoded figure.

Handling a 429

// HTTP 429, header: Retry-After: 3
{
  "error": {
    "code": "rate_limited",
    "message": "rate limit exceeded; retry after the Retry-After interval",
    "requestId": "req_…"
  }
}
  1. Read the Retry-After response header (seconds).
  2. Wait at least that long.
  3. Retry the request.
  4. If you're making many calls, add jitter and exponential backoff so a fleet of clients doesn't retry in lockstep.
resp = call()
if resp.status == 429:
  wait(seconds = resp.header("Retry-After") + jitter)
  retry with exponential backoff

Staying under the limit

  • Cache reads. Studio/source/destination lists change slowly; don't poll them in a tight loop.
  • Page with a large limit. Fetch up to 200 items per request instead of many small pages (see Pagination).
  • Use one key per integration. Because buckets are per-key, splitting distinct workloads across distinct keys keeps one busy job from starving another — and makes it easy to revoke just one.
  • Back off on 429, don't hammer. A client that ignores Retry-After and retries immediately just stays rate-limited.

Limits and tiers will be documented here as they firm up. For now, build against the 429 + Retry-After contract and you'll be forward-compatible.