I would be interested in the official line too. I always figured it’s per API key…

Here’s the response I got:

Right now rate limiting is done by API key and source IP address. We have plans to change it to API key and base ID in the future.

How many requests per seconds has the plus and pro account?

AFAIK they’re all identical. Only the Enterprise version has custom limits.

It mean currently an User IP can request API 5 times/second, isn’t it?
Thank you!

You are correct sir.

Does it mean that in case of having 5 parallel calls to Airtable each executed in 200ms I then need to wait for 800ms to start requesting AirTable again?

You can do 5 calls in one second. Not 5 in 800ms. :slightly_smiling_face:

But you’ll get an error back when you’re too quick…

I meant does it matter if I’ll have those 5 calls evenly distributed over the second or I do all of them together?

I’m not sure how they calculate it, but I’ve fired bursts of calls (like you) before without running into problems…

From my testing, it looks as though 429 Rate Limiting currently occurs on a per-IP Address basis only, regardless of API Key used or Base queried.

For example, you could use 5 API keys, each querying a different base, and still get 429 Rate Limited because all the requests are coming from one IP Address.

@airtable_team do you know if this has been changed to “API key and base ID” yet? Thanks!

is this limitation still on Airtable ??

So, for example, if more than 100 people with different IPs access and record in one base from their cell phones, is there no problem?

Typically all their requests would go through the same server with the same API key.

To have all those different IP addresses, the code would have to run on the client, which would mean exposing the API key, which is a se unity risk. Or it would mean that users would have to provide their API keys, which has problems of its own.

In 2025, Airtable’s API rate limits still primarily operate on a per-API-key and source IP basis, meaning that requests from the same key and IP are grouped together.

The original 5-requests-per-second rule remains a good benchmark for stability, but teams now often manage this constraint by implementing distributed worker setups or caching layers to balance throughput.

If you’re orchestrating multiple apps hitting different bases under one account, the safest strategy is still to stagger requests or proxy them through separate keys where possible (https://airtable.com/developers/web/api/rate-limits).

You can also review Airtable’s latest guidance on optimizing API performance and automation triggers here: Airtable API best practices.

For modern architectures that require high-frequency, bidirectional data sync without worrying about rate limits, event-driven integration platforms like Stacksync can help. It handles rate limiting, authentication, and retries automatically while keeping systems like Airtable, Postgres, or Salesforce in real-time sync across any scale.