Make Airtable 429 "Rate limit exceeded": per-second limit or monthly API calls?

Fix Airtable 429 in Make: 5 requests per second per base vs the monthly API call limit, "Failed to load data (429)", and how to slow scenarios down.

Updated 15 Oct 2026 · ~7 min read

Disclosure: this guide has one affiliate link to Make, marked "affiliate link", and mentions our Fiverr fix service. Error messages, settings and limits come from Make Help Center / app docs, Airtable API docs and Make Community threads 101017 and 108653 checked on 15 October 2026; anything we could not confirm is flagged for review before publishing. We did not reproduce these in a live Make scenario for this guide. Prices, where mentioned, are as seen from the US.

Short answer: An Airtable 429 in Make means Airtable refused the call, not Make. There are two different 429s: the per-second limit (5 requests per second per base; Airtable then wants a 30-second wait) and the monthly API call limit of your Airtable plan (it lasts until the next month). Find out which one you hit first, because only the first one goes away with Sleep modules and retries.

Everything below works on Make's Free plan. We did not reproduce a 429 in our own Make account for this guide; the error texts come from Airtable's API docs and Make Community threads.

What Airtable's 429 means

Airtable's API docs say: "The API is limited to 5 requests per second per base." There is also a limit of 50 requests per second for all traffic using personal access tokens from one user or service account. When you go over, Airtable answers 429 Too Many Requests with the type RATE_LIMIT_REACHED and the message "Rate limit exceeded. Please try again later", and you "will need to wait 30 seconds before subsequent requests will succeed."

Make shows a 429 as a RateLimitError. Make's rate limit help page says the rate limit error in Make corresponds to HTTP 429, and it names Airtable as one of the apps that often hits it when a scenario processes many records in a short time.

Airtable's own troubleshooting article adds a second 429: when you have used up the plan's monthly API call limit, the error type is PUBLIC_API_BILLING_LIMIT_EXCEEDED and the fix is to wait for the first day of the next month or change plan. Airtable's troubleshooting article gives the monthly limits: 1,000 API calls on the Free plan and 100,000 on the Team plan; Business and Enterprise plans have no monthly call limit.

Which 429 do you have?

In Make Community thread 108653 (May 2026) the user could not pick a table in Watch Records, opened the workspace settings in Airtable and found that the monthly API calls were used up. That is the second row.

"Failed to load data (429)" on one base only

Thread 101017 (January 2026) describes the Table dropdown in Airtable Search Records failing with "Failed to load data (429)" for one base while another base on the same connection worked. A community member suggested testing Airtable's metadata endpoint directly:

1. Add Airtable › Make an API Call with the same connection.
2. URL: v0/meta/bases/{baseId}/tables (the base ID starts with app and is in the Airtable URL). Method: GET.
3. Click Run this module only.

If this returns 200, the problem is in how the module loads the list, so open a ticket with Make support. If it also returns 429, the answer comes from Airtable, so take the evidence to Airtable support. In that thread the direct call also returned a 429 RateLimitError with origin Airtable, and the user took it to Airtable. The thread has no confirmed fix.

What Make does after a 429

If the Airtable module has no error handler, Make's help page lists what happens:

• Scheduled scenario: Make pauses the next scenario run for 20 minutes. With incomplete executions enabled, it also reruns the stored incomplete execution with exponential backoff.
• Instant scenario (webhook trigger): Make reruns the execution with exponential backoff.

Turn on Store incomplete executions in Scenario settings so the failed bundle is kept. A RateLimitError is one of the error types Make retries automatically from incomplete executions.

How to stop hitting the per-second limit

1. Use bulk modules. Make's Airtable app has Bulk Create Records (advanced), Bulk Update Records (advanced) and Bulk Upsert Records (advanced). Airtable's create and update endpoints take up to 10 records per request, so batching can cut the number of calls. Make's module docs don't say how the Bulk modules split larger arrays, so test with your own data. Put an aggregator in front to build the array (see iterator vs aggregator).
2. Process fewer records per run. Make recommends a limit of up to 20 records per run for frequently scheduled scenarios; set it in the trigger's Limit field.
3. Slow instant scenarios down. Set Maximum runs to start per minute on the instant trigger (the lightning icon or Schedule setting).
4. Add a Sleep module before the Airtable module that fails. Make's Sleep waits up to 300 seconds. At 5 requests per second per base, even a 1-second pause per bundle keeps a single route well under the limit.
5. Add a Retry error handler (formerly Break) on the Airtable module with automatic completion, so a rare 429 is retried later instead of failing the run. Don't use Skip (formerly Ignore) here: it drops the record.
6. Count every scenario. The 5 per second limit is per base, so two scenarios writing to the same base at the same moment share it. Spread their schedules.

Read requests can also be cut: one Search Records with a formula instead of a Get a Record per bundle. Airtable's docs suggest a caching proxy if you expect a high read volume.

If you hit the monthly limit

No amount of Sleep fixes this one. Open the Airtable workspace settings and check API usage (the Make announcement points there). Then either wait until the limit resets on the first day of next month, upgrade the Airtable plan, or cut the calls: polling triggers such as Watch Records call Airtable on every scheduled run even when nothing changed, so a 1-minute schedule spends calls all day. A longer interval, or a webhook pushed from an Airtable automation, uses far fewer.

The same thinking applies to Make credits. See Make credits explained.

Sources checked (15 October 2026)

• Airtable Web API: Rate limits and Errors
• Airtable Support: Airtable API: Common troubleshooting (TOO_MANY_REQUESTS, PUBLIC_API_BILLING_LIMIT_EXCEEDED)
• Make Help: Fix rate limit errors; Make apps: Airtable
• Make Community: 101017, 108653, 66395

Don't have a Make account yet? You can build and test this scenario on Make's free plan.

Create a free Make account (opens Make in a new tab)

Affiliate link: Flowpaja may earn a commission at no extra cost to you.

FAQ

What does a 429 from Airtable mean in Make?

Airtable refused the request because a limit was hit. Make shows it as a RateLimitError. It is either the 5 requests per second per base limit or the monthly API call limit of the Airtable plan.

How long do I have to wait after an Airtable 429?

For the per-second limit, Airtable's docs say to wait 30 seconds before new requests succeed. For the monthly limit (PUBLIC_API_BILLING_LIMIT_EXCEEDED) the limit resets on the first day of the next month.

Does Make retry an Airtable 429 automatically?

With incomplete executions enabled, yes: RateLimitError is retried with exponential backoff. Scheduled scenarios also pause the next run for 20 minutes.

Why does the Table dropdown say Failed to load data (429)?

Make could not load the table list from Airtable. Test GET v0/meta/bases/{baseId}/tables with Airtable Make an API Call: a 429 there points to Airtable, a 200 points to Make support.