Rate limits
120 requests per minute per key. The limit is counted per key rather than per address, because an integration calls from one server and an address limit would be measuring the wrong thing.
Reading your budget
Every answered request carries the current state of the window, so you never have to guess how much is left.
Requests allowed in the window, normally 120.
How many are left before the key is throttled.
Unix timestamp in seconds at which the window rolls over and the allowance is whole again.
Seconds to wait before trying again. Honour this in preference to a delay of your own.
When you go over
The request is refused with 429 and never reaches the endpoint, so nothing was read or written.
{
"title": "Too Many Requests",
"status": 429,
"detail": "this API key is sending requests too quickly. Slow down and try again shortly"
}Staying under it
- Cache what does not change. An organization’s timezone and currency are worth reading once at startup rather than before every call.
- Do not poll in a tight loop. The limit is generous for event-driven work and tight for a loop with no delay in it. Outbound webhooks do not exist yet, so polling is how you notice a change, but polling once a minute is plenty for anything this API currently exposes.
- Give each integration its own key. The budget is per key, so a chatty job then cannot starve the one that matters.
A 429 is recorded in your access log like any other call, so a job that keeps hitting the limit is visible after the fact.