How to build for them
- Back off on rejection, exponentially, with jitter. A tight retry loop against a limit is indistinguishable from an attack and gets treated accordingly.
- Batch where the endpoint supports it. One request for fifty records beats fifty requests.
- Do not poll aggressively. In the absence of outbound webhooks, polling is necessary — polling every second is not. Match the interval to how fast the data actually changes.
- Spread scheduled work. Every integration in the world runs at midnight. Pick a different minute.
- Cache what does not change. A chart of accounts does not need re-fetching on every request.
Bulk loading a year of history, or extracting an entire ledger, will hit limits designed for ongoing integration traffic. Tell us before you start. It is a five-minute conversation that avoids a half-loaded import and a lot of confused retrying.
Sign-in has its own protections
Authentication endpoints are protected separately from data APIs, and repeated failures against them are throttled harder than an ordinary rate limit. Two things follow that are worth knowing.
- Do not automate sign-in retries. A script that repeatedly attempts a login on failure will lock the path out faster than a person would.
- A stale credential in an automated process is the usual cause. It retries on a schedule, fails every time, and eventually the account is throttled for everybody — including the person trying to fix it.
Anything automated should authenticate with an API key, never by driving the sign-in form. Keys are built for it; sign-in is protected against it.
What this does not do
They change. Build to back off rather than to a figure.
Not configurable per workspace.
Talk to us about genuinely high-volume needs instead.
An exceeded request is rejected, not held.
Questions
What are the actual numbers?
Not published, because they change. Handle rejection properly and you will not need them.
Can we raise a limit?
For a specific, described need — ask.
Do limits apply per key or per organisation?
Broadly per key and endpoint. Spreading load across keys to evade a limit is not a supported approach.