Why You Are Getting Airtable Error 429 (And How to Fix It)

Error 429 means Too Many Requests. Airtable returns this when your integration exceeds one of two separate API limits: the per-second rate limit, or your plan's monthly API call quota. Both produce the same 429 status code, but they have different causes and different fixes.

The Two Limits That Cause 429

Per-second rate limit

Airtable enforces a limit of 5 requests per second per base. If your integration sends more than 5 API calls to the same base within a single second, the requests above the limit receive a 429 response.

This limit is the same on every plan and cannot be increased. It applies per base, not per account. If you have two bases, you can send 5 requests per second to each simultaneously without triggering 429s.

Monthly API call quota

Every Airtable plan includes a fixed number of API calls per workspace per month. Once you hit that quota, all further API calls return 429 until the next billing cycle resets your count.

The monthly limits by plan are:

If your workspace is on the Free or Team plan and you are seeing 429 errors consistently rather than in short bursts, a depleted monthly quota is the likely cause. Check your workspace usage in your billing settings before assuming the problem is request pacing.

What Causes Per-Second 429 Errors

Loops without delays. A script that loops through 100 records and makes an API call for each one will fire 100 requests almost simultaneously. Even a fast loop hits the rate limit within the first second.

Multiple automations triggering at once. If 20 records are updated at the same time and each triggers an automation that makes an API call, you can generate 20 simultaneous API requests instantly.

Integrations with no backoff. Some integration tools (Zapier, Make, custom scripts) do not automatically slow down when they receive a 429. They retry immediately, which triggers more 429s in a loop.

How to Fix Per-Second 429 Errors

Add delays between requests in scripts

In any Airtable script or external code that loops through records and makes API calls, add a delay between each request.

A 200ms delay between requests keeps you well under the 5 requests per second limit:

async function sleep(ms) {
  return new Promise((resolve) => setTimeout(resolve, ms));
}

for (let record of records) {
  await table.updateRecordAsync(record.id, { field: value });
  await sleep(200); // 200ms pause between each request
}

This adds a small amount of total processing time but eliminates burst 429 errors completely.

Use batch operations instead of individual requests

Airtable's API supports updating up to 10 records in a single request. Instead of 10 separate update calls, send one batch call with all 10 updates. This reduces your request count by 10x.

In Airtable scripts, use updateRecordsAsync (plural) instead of updateRecordAsync (singular) and pass an array of record objects:

await table.updateRecordsAsync([
  { id: record1.id, fields: { Status: "Done" } },
  { id: record2.id, fields: { Status: "Done" } },
  // up to 10 records per call
]);

For creates and deletes, createRecordsAsync and deleteRecordsAsync both support batches of up to 10 as well.

Handle 429 responses with exponential backoff

In external integrations, implement retry logic with exponential backoff. When a 429 is received, wait before retrying. Double the wait time with each subsequent 429:

async function apiCallWithRetry(fn, maxRetries = 5) {
  let delay = 1000; // start with 1 second
  for (let i = 0; i < maxRetries; i++) {
    try {
      return await fn();
    } catch (err) {
      if (err.statusCode === 429 && i < maxRetries - 1) {
        await sleep(delay);
        delay *= 2; // double the wait each time
      } else {
        throw err;
      }
    }
  }
}

In Make or Zapier

If the 429 is coming from a Make or Zapier scenario, check whether the scenario is set to run multiple times simultaneously. If you are processing many records in a short window, limit concurrent executions and add a short delay module between Airtable API calls within the scenario.

Make has a built-in Error Handler module that can retry on 429 with a configurable delay. Set this up on any Airtable module in your scenario that risks hitting the rate limit.

How to Fix Monthly Quota 429 Errors

If you have exhausted your monthly quota, there are three options.

Wait for the billing cycle to reset. API access restores automatically at the start of the next month. If the quota depletion is a one-off (a large data migration, for example), this may be all that is needed.

Reduce how many API calls your integration makes. Batch operations help here too. Ten record updates sent as one batch call count as one API call against your quota, not ten. Auditing your automations and scripts for unnecessary calls can meaningfully extend how far your monthly quota goes.

Upgrade your plan. If you are regularly hitting the quota on the Free plan (1,000 calls per month), the Team plan (100,000 calls per month) is a significant step up. If you are on the Team plan and still running out, the Business plan removes the monthly limit entirely.

Checking Whether 429s Are Causing Silent Failures

In Airtable automations, a 429 from a Run script action typically causes the automation to fail silently or show a timeout error rather than an explicit 429 message. Check your automation run history if records are not being updated as expected. For how to read the run history and set up failure notifications, see how to monitor your Airtable automations.