Limits
Single-record reads such as
GET /v1/call-log/{id} and GET /v1/scored-calls/{id} count toward
everything else, not heavy reads.
These are the current limits. Salesfinity gives notice in the changelog before
lowering any of them.
How requests are counted
- Windows start on the minute. A window runs from one clock minute to the next, not for 60 seconds after your first request, and the count starts again at zero when it closes.
- Each bucket counts on its own. A team at its heavy-reads limit can still make Sequencer calls and everything else.
- A refused request still counts. Retrying before the window closes is refused again, so wait
for
Retry-Afterrather than retrying in a loop. - Every authenticated request counts, whatever its outcome. A 400, a 404 for a record
outside your team, and a Sequencer write answered from its
Idempotency-Keyall count. - Only authenticated requests count. A request without a valid API key gets 403 and is not counted, and neither is a request to a path that matches no route.
Response headers
Every response to an authenticated request carries three headers for the bucket it counted against:
Treat the headers as optional. On the rare occasion a request cannot be counted, it goes through
without them rather than failing.
When you hit a limit
Over a limit, the request is refused with 429 Too Many Requests. TheRetry-After header gives
the seconds until the window closes, from 1 to 60, and the body uses the usual
error envelope:
Retry-After, then send the same request again, including a POST that is otherwise not safe to
retry. The X-RateLimit-* headers come on the 429 as well.
Pacing a bulk job
Rather than waiting for a 429, readX-RateLimit-Remaining on each response and pause for
X-RateLimit-Reset seconds when it reaches zero:
Retry-After of up to 30 seconds
and sends the request once more, and reports a longer wait as an error.