Start Here

Rate limits

Workspace limits, response headers, and client backoff guidance
View as Markdown

Authenticated requests to /api/v2 resource routes are rate limited per workspace, not per API key or OAuth token. The limit is 1000 requests per 60-second window, shared across every credential issued for that workspace. The limit applies to all HTTP methods on v2 resource routers (for example GET, POST, PATCH, and DELETE on contacts, companies, engagements, tags, users, and transcript resources)—not read-only traffic alone.

Response headers

Every successful authenticated response includes proactive rate-limit headers so clients can monitor usage without waiting for a 429:

HeaderWhen presentMeaning
X-RateLimit-LimitAll authenticated responsesMaximum requests allowed in the current window (1000)
X-RateLimit-RemainingAll authenticated responsesRequests remaining before the limit is exceeded
X-RateLimit-ResetAll authenticated responsesUnix epoch seconds when the current window resets
Retry-After429 onlySeconds to wait before retrying after the limit is exceeded

If rate-limit enforcement is temporarily unavailable, the API returns 503 with a problem response. Retry after a short delay; successful responses are not returned in that state.

Guidance for integrators

  • Read X-RateLimit-Remaining and X-RateLimit-Reset on every response to pace workers before hitting the limit.
  • Handle 429 explicitly and respect Retry-After before retrying.
  • Use cursor pagination instead of aggressive polling.
  • Back off with jitter when multiple workers share the same workspace credential.

If your use case needs predictable high-volume sync, tell us the expected throughput so limits can be tuned to something more scientific than vibes and coffee.