Skip to main content
Request capacity depends on the deployed API configuration and any gateway limits. Do not assume one fixed budget applies to every endpoint or organization. Contact support for capacity planning for your integration. Send events and Identify a session share their own request budget, separate from the rest of the API, so a large event sync does not use up the capacity of your other requests. Requests that carry anonymous events (a session_id and no contact data) also count against a second, smaller budget, because website traffic can grow without bound: batch those events instead of sending one request per page view.

​
Handle 429 responses

If a request returns 429 Too Many Requests, stop issuing requests in a tight loop. Use Retry-After when present. It can describe a delay in seconds or an HTTP date. If absent, use bounded exponential backoff with jitter and reduce concurrency. When rate-limit headers are returned, interpret them according to the gateway contract for that endpoint. Do not assume X-RateLimit-Reset is always a duration rather than a timestamp, or that all responses include the same header family.

​
Paginate reads

Send limit and offset together on endpoints that support them. Begin with a modest positive page size and offset zero. Keep filtering and ordering consistent and use the returned pagination values to determine completion. Pagination parameters are not supported by every list endpoint.

​
Retry according to the operation

Keep a log of request time, endpoint, status, and your own correlation identifier. Remove API keys and unnecessary personal data from logs shared with support. See API introduction, List contacts, Send events, Identify a session, and Call webhooks.