Rate limits

The gateway limits how fast each tenant can call the API, so one busy integration can't starve the rest. The limit is per tenant — shared across every key and user in that tenant, not per key.

The limit

Each tenant gets a steady rate plus a short burst allowance:

• 100 requests per second, sustained.
• 200 requests of burst headroom for momentary spikes.

Most integrations never come close. High-volume jobs — bulk imports, backfills — are the ones that need to pace themselves.

When you exceed it

A request over the limit gets:

HTTP/1.1 429 Too Many Requests
Retry-After: 1

The Retry-After value is the number of seconds to wait before trying again. The gateway does not return running X-RateLimit-* counters — treat a 429 as the signal and back off.

Handling it

Honor Retry-After, then retry with exponential backoff and jitter. Only safe, repeatable requests should be retried automatically — see Retries & idempotency.

async function callWithRetry(request, { maxRetries = 5 } = {}) {
  for (let attempt = 0; ; attempt++) {
    const res = await request()
    if (res.status !== 429 || attempt >= maxRetries) return res

    const retryAfter = Number(res.headers.get('retry-after')) || 1
    const backoff = retryAfter * 1000 + Math.random() * 250 // jitter
    await new Promise(r => setTimeout(r, backoff))
  }
}

Staying under the limit

• Batch where the capability supports it instead of looping one item at a time.
• Cache responses you read repeatedly; watch the X-Cache header to confirm cacheable reads are being served from cache.
• Spread bulk work over time rather than firing it all at once.