APIv3
Exit Documentation

Rate limits

API rate limits protect SalesBinder accounts and maintain reliable service for every integration. Limits are applied independently to each authenticated API key.


Default allowance

Each API key can make 120 authenticated requests during a 60-second window by default. Requests made with another API key use that key's separate allowance, even when both keys belong to the same user or account.

Every authenticated request consumes one request from the allowance. This includes requests that return validation or permission errors and requests that replay an earlier idempotent response.


Response headers

Authenticated API responses include:

http
RateLimit-Limit: 120
RateLimit-Remaining: 117
RateLimit-Reset: 38
HeaderDescription
RateLimit-LimitMaximum requests available in the current window.
RateLimit-RemainingRequests remaining after the current request.
RateLimit-ResetSeconds until a new allowance window begins.

Authentication failures do not identify an API key and therefore do not include per-key allowance headers.


When the limit is exceeded

Requests beyond the current allowance return 429 Too Many Requests:

http
HTTP/1.1 429 Too Many Requests
RateLimit-Limit: 120
RateLimit-Remaining: 0
RateLimit-Reset: 12
Retry-After: 12
Request-Id: req_1d352b4e6502b1edda090f4b210a8cfc
json
{
  "error": {
    "type": "rate_limit_error",
    "code": "rate_limit_exceeded",
    "message": "Too many API requests. Please retry shortly."
  }
}

Retry-After is the number of seconds the integration should wait before trying again. The request is rejected before an API action runs, so a rate-limited write does not create or modify a resource.


Retry safely

When a request returns 429:

  1. Wait for the number of seconds in Retry-After.
  2. Retry with a small amount of random delay so multiple workers do not all resume simultaneously.
  3. Keep concurrent workers within one shared allowance for the API key.
  4. Reuse the original Idempotency-Key when retrying a supported write operation.

Do not immediately retry a 429 response in a tight loop. If an integration regularly reaches the allowance, reduce polling, request larger supported pages, and coordinate concurrency across workers.