Airtable API Rate Limit (429 Error): Why It Happens and How to Fix It

A practical field guide from Automation Ace.

Airtable API Rate Limit (429 Error): Why It Happens and How to Fix It

If your Airtable integration works fine at low volume and then starts failing under load with "429 Too Many Requests," you have hit Airtable's rate limit. Airtable enforces roughly 5 requests per second per base, and once you exceed it the API refuses further requests for a short cooldown. The fix is not to retry harder — it is to send fewer, smarter requests. This guide explains the limit and the patterns that respect it.

What the 429 actually means

A 429 is Airtable telling you to slow down. After you exceed 5 requests per second on a base, subsequent requests are rejected for about 30 seconds. Naive retry loops make this worse: they keep firing during the cooldown and extend it. The correct response is to back off, wait, and reduce your request rate.

Batch your reads and writes

The single biggest win is batching. The Airtable API accepts up to 10 records per create, update, or delete request. If you are writing 100 records one at a time, that is 100 requests; batched into tens, it is 10 requests. Always group records into batches of 10 rather than looping single-record calls. The same applies to reads — page through with larger page sizes instead of many small queries.

Throttle to stay under 5 per second

When you cannot avoid many requests, pace them. In a Code step, add a short delay between calls so you never exceed five in any one-second window. In Zapier, sequence steps rather than fanning out parallel calls, and insert Delay steps in loops. Deliberate throttling is far more reliable than hitting the wall and retrying.

Cache and de-duplicate lookups

Repeatedly asking Airtable "does this record exist?" for the same keys wastes your budget. Cache results within a run, and for cross-run de-duplication keep a ledger so you are not re-querying. Fewer redundant lookups means fewer requests overall.

Handle 429 gracefully when it still happens

Even well-designed integrations occasionally get a 429 during spikes. Implement exponential backoff: on a 429, wait, then retry with a longer wait each time, rather than immediately hammering again. Respect any retry timing Airtable provides. Combine this with error handling so a temporary limit does not lose data — see the durable recovery patterns in the error handling playbook.

Watch out for hidden multipliers

Loops, line-item processing, and Zaps that fan out one trigger into many Airtable calls are the usual reason a low-traffic base suddenly hits the limit. Count how many Airtable requests a single trigger actually generates end to end. If your Airtable API integration is buckling under real volume, Automation Ace can re-architect it around batching and throttling so it stops throwing 429s.