Rate Limits
Every company has a request budget that depends on its license tier. When the budget is exceeded, the API responds with 429 rate_limit_exceeded. For general error handling, see Error Handling.
License tiers and limits
| Tier | Requests per minute | Requests per day |
|---|---|---|
| Basic | 20 | 150 |
| Premium | 300 | 10,000 |
This table is also the key to the 429 response: the response body includes plan (basic or premium) and limit — the exact number the request failed against. The combination tells you whether the per-minute or the per-day limit applied. Example: plan: "basic" with limit: 20 means the per-minute limit, limit: 150 means the per-day limit.
For more on the tiers and how to book Premium, see License Tiers.
Limits apply per company
Limits apply per company, not per API client. If a company creates multiple API access credentials, all of them share the same budget.
If you're an integration partner managing multiple practices, each practice has its own budget. Limits are never combined across companies — not even when your requests share the same IP address.
Sliding window
Limits use a sliding window, not a fixed reset at midnight. Once the daily budget is used up, the quota replenishes continuously — on Basic, roughly one request every ten minutes.
This means: exhausting your daily budget doesn't lock you out until midnight — it throttles you heavily for the following 24 hours.
Rate limit headers
Every response — including successful ones — includes three headers:
| Header | Description |
|---|---|
X-RateLimit-Limit | The limit that applies to the current request. |
X-RateLimit-Remaining | How many requests are left in the current budget. |
X-RateLimit-Reset | The point in time from which the next request is allowed. |
Note:
X-RateLimit-Resetis not the time of a window reset — a sliding window has no window boundary. The header carries the time from which the next request is allowed. If budget remains, that time is effectively now.
Check these headers to know your remaining budget instead of reacting only after a 429 response.
Recommendations for bulk requests
An initial sync or full synchronization can hit the daily limit before it completes. Store the last processed position and resume from there instead of starting over at offset=0 the next day. Otherwise the sync never finishes.
Also avoid requesting a new access token for every operation. A token is valid for one hour — reuse it instead of requesting a new one repeatedly.
Token endpoint limits
Requesting access tokens at the /api/oauth/v2/token endpoint is rate limited separately from other API calls. Successful token requests also count against the company budget for the applicable license tier. Every token attempt from a client also counts against its own, much stricter limit — regardless of whether it succeeds or fails, for example due to an incorrect client secret or an unknown client ID.
If you reuse your access token instead of constantly requesting a new one, you won't notice these limits in practice.