Avaza applies rate limits to the API to keep the platform fast and reliable for everyone. This article explains each limit, how it is measured, what happens when you exceed one, and how to reduce the number of calls your integration makes.
The limits
| Limit | What it counts | Threshold |
|---|---|---|
| Per application, per minute | All calls made by one application, across every Avaza account it connects to | 10,000 per minute |
| Per application, per account, per minute | All calls made by one application against one account | 250 per minute |
| Per application, per account, per day | All calls made by one application against one account | 5,000 per day |
| Per account, per minute | All calls from every application and token on one account, combined | 1,000 per minute |
| Per account, per day | All calls from every application and token on one account, combined | 20,000 per day |
| Failed authentication, per IP address | Requests sent with an invalid or expired token from one IP address | 100 per 15 minutes |
Each limit is applied independently. A request must pass all of them.
How the limits are measured
Limits are per application, not per user. Every user in your account who works through the same application draws from the same allowance. If twenty staff members use one integration, those twenty people share 250 calls per minute and 5,000 calls per day between them. Adding more users does not increase the allowance.
Each Personal Access Token counts as its own application. A token receives its own 250 calls per minute and 5,000 calls per day, separate from any OAuth application and from any other token.
The account limits sit above everything else. The 1,000 per minute and 20,000 per day figures count all of your applications and tokens together. Registering an additional application gives that application its own allowance, but it does not raise your account total.
Failed authentication is measured per IP address, and is checked before your token is validated.
Windows and resets
All limits use fixed windows measured in UTC:
- Per-minute limits reset at the start of each UTC minute.
- Daily limits reset at 00:00 UTC, not at midnight in your account’s timezone.
- The failed-authentication window is 15 minutes.
If your account is set to Sydney time, your daily allowance resets mid-morning local time. If your account is set to US Pacific time, it resets in the late afternoon of the previous local day.
Checking your usage
Every API response includes headers showing where you stand against whichever limit currently has the least headroom:
| Header | Meaning |
|---|---|
| X-RateLimit-Limit | The threshold being reported |
| X-RateLimit-Remaining | Calls remaining in the current window |
| X-RateLimit-Reset | When the window resets, as a UTC timestamp in seconds |
Because these headers always report your tightest constraint, the limit they describe can change during the day — you may see your per-minute application limit at one point and your daily account limit at another.
What happens when you exceed a limit
The request returns HTTP 429 Too Many Requests, with a JSON body identifying which limit was reached and a Retry-After header giving the number of seconds until that window resets.
Your integration should stop sending requests and wait before retrying. Retrying immediately will simply consume the next window.
One note on Retry-After: if you have reached a daily limit, the value can be several hours. Most applications should treat it as a signal to pause and reschedule rather than sleeping for the full duration.
Examples
One integration, many users. An agency with twenty staff runs a single integration. All activity flows through one application, so all twenty users share 250 calls per minute and 5,000 calls per day.
Two applications on one account. The agency registers a second application for a reporting job. Each application now has its own 250 per minute and 5,000 per day. Their combined traffic is still bounded by the account limits of 1,000 per minute and 20,000 per day.
Reaching the account limit. Four applications each running at their full 5,000 calls per day reach the 20,000 daily account limit. A fifth application will receive 429 responses even though its own daily allowance is untouched.
Personal Access Tokens. A developer creates three tokens for three scripts. Each token has its own 250 per minute and 5,000 per day. All three still count toward the account limits.
Several tools on one account. An account connects Zapier, Make, and a custom integration. Each has its own allowance, but if their combined traffic reaches 1,000 calls in a minute, all three receive 429 responses even though none of them individually exceeded 250 per minute.
An application serving many customers. A vendor’s application is installed on sixty Avaza accounts. Each installation has its own 250 calls per minute, and the application as a whole is capped at 10,000 calls per minute across all of them. Vendors should stagger scheduled jobs so that every customer’s sync does not run on the same minute.
Failed authentication. A customer rotates a client secret but leaves an old scheduled job running with the previous token. After 100 rejected requests within 15 minutes from that server, further requests from that IP address are rejected until the window resets. Because this check runs before token validation, valid requests from the same IP address are also affected during that period.
Reducing the number of calls you make
Most integrations that hit a limit are re-fetching data that has not changed. These changes usually resolve it:
Use the UpdatedAfter parameter. Avaza’s GET endpoints accept an UpdatedAfter parameter that returns only records created or modified since the timestamp you supply. Store the time of your last successful call and pass it on the next run, so each sync retrieves only what has actually changed. This is the single most effective change most integrations can make — a job that pulls a full data set every run and compares it locally is doing almost all of that work for nothing.
Use webhooks instead of polling. Webhooks notify you when something changes, rather than requiring you to ask. A job polling one endpoint every minute uses 1,440 calls a day before it does anything useful.
Request larger pages. Use the largest sensible page size rather than retrieving records one at a time.
Filter on the server. Apply date, status and other filters in your request instead of downloading everything and filtering in your own code.
Cache reference data. Users, projects, categories and similar records rarely change between runs and do not need to be re-fetched each time.
Stagger scheduled jobs. Avoid starting every job on the hour or on the same minute boundary.
Read the rate-limit headers. Slow down when X-RateLimit-Remaining gets low, rather than waiting for a 429.