The Airtable API is limited to 5 requests per second per base. There's also a limit of 50 requests per second for all traffic using personal access tokens from one user or service account. Go over either and you'll get a 429, and you have to wait 30 seconds before requests succeed again.
Two meters running at once
It helps to think of the limits as two separate meters. One counts requests to each base: no more than 5 a second. The other counts every request made with one person's or one service account's personal access tokens, across all their bases: no more than 50 a second. Whichever meter you hit first is the one that stops you.
For a small business with one or two bases and a single integration, the per-base meter is nearly always the one that matters. The per-token meter starts to bite when one account runs lots of automations across many bases at the same time, say an agency service account syncing a dozen client bases.
| Item | Limit | Applies to |
|---|---|---|
| Requests per base | 5 per second | All API traffic to one base |
| Requests per user token | 50 per second | Personal access tokens from one user or service account |
| Wait after a 429 | 30 seconds | Any rate-limited request |
| Records per page | 100 (default 100) | List records pageSize |
| Payload size | No number published; 413 returned when exceeded | Any request |
What the 429 looks like
A rate-limited request comes back with a 429 status code, the error type RATE_LIMIT_REACHED and the message 'Rate limit exceeded. Please try again later'. Then comes the part that hurts: you must wait 30 seconds before later requests will succeed.
That 30-second penalty is why the Airtable Web API page on rate limits matters more than the raw numbers. The 5 per second limit is per base, not per account, but the 50 per second token limit is shared by every base a user's tokens touch. And because of the penalty, retrying immediately makes things worse: each instant retry is another request into a window that's already closed.
A retry pattern that respects the penalty
- Pace your requests to stay under 5 a second per base, with a little headroom.
- On a 429, stop sending to that base and wait at least 30 seconds.
- Back off further if a second 429 arrives, rather than retrying on a fixed timer.
- Log which base and which token hit the limit, so you can tell the two meters apart.
If you're writing JavaScript, the official airtable.js client has built-in back-off and retry logic, so you get most of this without writing it yourself.
Reading lots of records
List records returns one page at a time. The default pageSize is 100, and it can't be set higher than 100. So reading 10,000 records takes at least 100 requests, which at 5 a second is 20 seconds of steady calls to one base, before any writes.
For higher read volumes, Airtable recommends a caching proxy: one service reads from the base on a sensible schedule and everything else reads from the cache. That keeps a busy dashboard or website from spending your per-base allowance on the same records over and over.
If people inside the business need a read-only view of the data, an interface built with Interface Designer can save you building an external dashboard that polls the API at all. If you're choosing between pulling data and having it pushed to you, this explainer on APIs and webhooks covers the trade-off.
Payload size and future changes
A 413 error means a request went over the maximum payload size. Airtable doesn't publish a number for it and says you shouldn't hit it under normal use, so if you do, split the request into smaller batches.
Airtable also says it may change the enforced limits or add other kinds of limits, including tiers based on plan. Today the limits are the same across plans, but build your integration so the limits are settings you can change, not numbers baked into the code. Tools for monitoring API errors will flag a rise in 429s early if that ever happens.
Want AI doing the heavy lifting in your marketing?
I build the systems that handle the boring 80 percent, so you get your week back. Done properly, with the human kept in.
How other business APIs compare
Notion allows 600 requests per minute per connection on Business and Enterprise workspaces and 180 per minute on other plans. Help Scout's Inbox API lists up to 200, 400 and 800 calls per minute depending on plan. Zendesk's Support API lists 200, 400, 400, 700 and 2500 requests per minute across its five plan levels.
My advice for anyone syncing a base
Design for 4 requests a second per base and never retry a 429 straight away. Use airtable.js if you can, cache anything that's read often, and pull records in full pages of 100. Keep heavy jobs on separate service accounts so one busy automation can't use up the token limit for everything else.
Want your tool on this list? Featured spots and reviews here are paid partnerships. Here's how to partner with me.
Frequently asked questions
What is the Airtable API rate limit?
5 requests per second per base, plus 50 requests per second per user or service account across personal access tokens.
What happens if I hit it?
You get a 429 and must wait 30 seconds.
Does the JavaScript client handle it?
Yes. airtable.js has built-in back-off and retry logic.
How do I read more without hitting the limit?
Airtable recommends a caching proxy for higher read volumes.
How many records come back per request?
A page of up to 100 records, which is also the default.
