Airtable Rate Limits and 429 Errors

What a 429 Actually Means

429 Too Many Requests means your workflow asked Airtable for something faster than the API permits. Airtable rejects the extra requests rather than queuing them, and depending on how your workflow handles errors, it either retries, fails the run, or silently skips records.

It's rarely a sign you've outgrown Airtable. Almost always it's a workflow doing one request per record when it could do one request per batch.

Two things worth knowing about how the limit applies. It's enforced per base rather than per workflow, so three automations hitting the same base share one budget and each one looks innocent in isolation. And exceeding it repeatedly can lock the base out briefly, which turns a slow workflow into a stopped one.

Why It Almost Always Happens on Bulk Operations

Normal operation rarely gets near the limit. A record created every few minutes, a lookup here and there, no problem.

Then one of these happens.

Someone does a bulk edit. A person updates 400 records in the interface. Your update-triggered workflow fires 400 times, each doing its own read and write, and you've generated well over a thousand requests in a few seconds.

A migration or import runs. Loading historical data one record at a time.

A loop processes records individually. The workflow fetches 500 records then iterates, doing a separate write per record, when a single batched call would have done.

Several automations run at once. Each within limits alone, collectively over.

The common thread is per-record requests where per-batch would work.

The Four Fixes, In Order of Payoff

1. Batch your writes. Airtable's API accepts multiple records in a single create or update call. Most connectors expose this and most builds ignore it. Rewriting a loop that writes one record at a time into batched calls cuts your request count by roughly the batch size, which is usually the whole problem solved in one change.

2. Narrow the trigger. If your workflow fires on any record update, it fires on every field change including ones irrelevant to it. Trigger on a specific view, or on a specific field changing, so a bulk edit to an unrelated column doesn't wake it. This is the single best prevention because it stops the requests existing rather than managing them.

3. Add a delay between iterations. Crude and effective when you genuinely must process individually. A short pause per iteration keeps you under the ceiling. It makes runs slower, which is usually fine for a background job and unacceptable for something a customer is waiting on.

4. Handle the 429 properly. Retry with a backoff rather than failing the run. Wait, retry, wait longer, retry, then give up and alert. Many connectors have retry settings you can just switch on. What you must avoid is an immediate retry loop, which makes the situation worse and can extend the lockout.

Cache Instead of Re-Reading

A pattern that quietly doubles request counts: fetching the same reference data on every iteration.

A workflow processing 200 orders that looks up the customer record each time makes 200 lookups, many for the same customer. Fetch the reference table once at the start of the run, hold it in memory, and match against it. One request instead of 200.

Same principle for anything static within a run: field options, category mappings, price lists.

Design for the Bulk Edit You Didn't Plan

The bulk edit is the recurring cause and you can't stop people doing it.

So build for it. Cap how many records a single run may process, and alert rather than proceeding when the cap trips. A workflow that normally handles three records and suddenly matches 400 should stop, because whatever caused that is more likely a mistake than genuine growth.

That guard protects against more than rate limits. It's the same ceiling that prevents 400 accidental emails, which is why we put it on every build that touches records in volume. Why your automation sends duplicate messages covers the messaging side of the same failure.

When It Genuinely Is Volume

Occasionally the limit is a real signal rather than a design problem.

If you're consistently processing tens of thousands of records with legitimate per-record work, and batching and caching haven't fixed it, you're using Airtable as a transactional database rather than as an operational base. That's the point to ask whether the data belongs somewhere else, with Airtable holding the working set rather than everything.

Airtable vs Google Sheets for automation covers the thresholds where the storage choice starts mattering, and Airtable automation: what it can and can't do covers where the native layer stops.

Diagnosing Yours

Look at when the errors cluster. Same time daily suggests a scheduled job doing per-record work. Irregular bursts suggest bulk edits or imports. Constant suggests several automations sharing the base.

Then count the requests one run actually makes, which is usually higher than people estimate by a factor of several, because each lookup, each write and each read of a linked record is its own call.

Book a free 60-minute call and we'll find what's generating the volume, batch the operations that should be batched, and add the caps so a bulk edit stops being an incident.