Understanding Avaza API rate limits

Avaza limits how often the API can be called, to keep the service fast for everyone. This article lists the limits, explains how they're counted, and shows how to stay within them.

The limits

Each limit is checked separately, and a request must pass all of them.

How the limits are counted

• Per app, not per person. Everyone in your account who works through the same app shares its allowance. If twenty people use one integration, they share 250 calls a minute and 5,000 a day. More users don't raise it.
• Each personal access token counts as its own app, with its own 250 a minute and 5,000 a day.
• The account limits cover everything. The 1,000 a minute and 20,000 a day count all your apps and tokens together. A new app or token gets its own allowance, but the account total stays the same.
• Refused requests can still count. A request refused with 429 has usually been counted against the limits checked before it. An app that keeps calling after hitting its daily limit keeps using up the account's daily total, and can block your other apps too.
• Failed sign-ins are counted per IP address, before the token is checked. Only requests that send a token count, and a successful request doesn't reset the count.

Which apps count

• The Avaza MCP Server counts like any other app. Everyone in your account who connects an AI tool through it shares one allowance of 250 calls a minute and 5,000 a day. Those calls also count towards the account's 1,000 a minute and 20,000 a day, together with your other apps. An AI assistant often makes several calls for one request, so a busy team can reach the limit sooner than it expects. See Avaza MCP Server.
• Zapier counts too. Calls from your Zaps and from Zapier MCP count towards your limits in the same way as any other connected app's.

When limits reset

The per-minute and daily limits use fixed windows 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 time zone. If your account uses Sydney time, that's mid-morning. On US Pacific time, it's late afternoon the day before.

The failed sign-in count clears once 15 minutes pass without a failed request. A job that keeps retrying with an old token every few minutes never lets it clear. After 100 failures, every request from that IP address is refused for 15 minutes, even ones with a valid token.

Check your usage

Responses to requests with a valid token include three headers. They describe whichever limit you're closest to reaching:

Because the headers follow your tightest limit, the limit they report can change during the day. You might see the per-minute app limit in the morning and the daily account limit later.

When you go over a limit

The API answers HTTP 429 Too Many Requests. The JSON body names the limit you reached, for example "for this app on this account, for this UTC day", and the Retry-After header gives the seconds until that window resets.

Stop sending and wait. For a daily limit, Retry-After can be several hours, so pause the job and reschedule it rather than sleeping.

Two other rules also answer 429. After 100 failed sign-ins from one IP address, the title is "Too Many Failed Authentication Attempts". If an Administrator has set Limit bulk deletes under API permissions, deletes above that number per person per hour are refused until the next full hour. See getting started with the Avaza API.

Examples

• One integration, many users. An agency with twenty staff runs one integration. All twenty share 250 calls a minute and 5,000 a day.
• Two apps on one account. The agency adds a second app for reporting. Each app has its own 250 a minute and 5,000 a day, but together they're still held to 1,000 a minute and 20,000 a day.
• The account limit. Four apps each make their full 5,000 calls in a day, reaching the 20,000 account limit. A fifth app gets 429 even though it hasn't used any of its own allowance.
• Personal access tokens. A developer creates three tokens for three scripts. Each token has its own allowance, and all three count towards the account limits.
• Several tools at once. Two connected apps and a script together make 1,000 calls in one minute. All three get 429 for the rest of that minute, even though none reached 250 on its own.
• An app used by many customers. A vendor's app is connected to sixty Avaza accounts. Each account gets its own 250 a minute from it, but the app as a whole is capped at 10,000 a minute. Stagger scheduled jobs so every customer's sync doesn't start in the same minute.
• An old token. Someone deletes a personal access token but leaves a scheduled job running with it. After 100 refused requests from that server, all requests from its IP address are refused until 15 minutes pass without another failure.

Make fewer calls

Most integrations that hit a limit are downloading data that hasn't changed.

• Use UpdatedAfter. Most list endpoints (projects, tasks, timesheets, expenses, invoices, companies, contacts and more) accept it and return only records created or changed since that time. Store the time of your last successful sync and pass it next time. This is the biggest saving for most integrations.
• Use webhooks instead of polling. A job that checks one endpoint every minute makes 1,440 calls a day before it finds anything. Webhooks tell you when something changes.
• Ask for bigger pages. List endpoints return 20 records a page unless you set pageSize, which goes up to 1,000.
• Filter on the server. Use the date, status and other filters in the request instead of downloading everything and filtering it yourself.
• Cache reference data. Users, projects and categories rarely change between runs.
• Stagger scheduled jobs. Avoid starting every job on the hour.
• Watch the headers. Slow down when X-RateLimit-Remaining gets low, rather than waiting for a 429.
• Refresh expired tokens instead of retrying with them. See OAuth 2.0 for the Avaza API.