Airtable API limits and pricing: estimate your monthly calls

Is the Airtable API free to use?

Start with the workspace that owns the base your integration calls. API requests, stored records, automation runs and paid collaborators are different units. This guide reviews the official documents on 16 October 2026 and supplies an original planning calculator and fictional call ledger.

The Airtable profile explains the broader product. Airtable versus Smartsheet covers structured work, record capacity and collaborator costs.

Which API limits belong to the plan?

The plan overview lists the workspace’s monthly allowance. The pricing page explains paid workspace/seat offers. An API allowance is one part of the retained subscription; your connector or automation provider can also charge separately.

A base’s record and attachment capacity is a different constraint. A larger API allowance does not establish that a base can store any number of records. Keep the plan, collaborators, record/storage needs and integration costs with the buying brief.

Why does listing 230 records need three requests?

The Web API introduction explains pagination: a list response returns at most 100 records. The List records reference describes the returned offset used to request another page. Follow the returned offset until the response indicates there is no next page.

For a stable fictional result set of 230 records, full-size pages hold 100, 100 and 30 records: three read requests. A smaller requested page size can require more calls. An empty result still requires the initial list request; zero returned records does not mean zero requests.

The estimator assumes one complete list operation per run with pages of up to 100 records. It does not measure a changing table, request timing or API results. Reconcile actual records and pagination before treating a successful first page as a complete extract.

How does batching change the update count?

Airtable’s API call management guide describes batching up to ten records per request. The multiple-record update reference documents the update operation. For the example, update twelve distinct existing records in two batches: ten and two.

That makes three read requests plus two update requests, five calls per run. Sending twelve individual updates would make fifteen calls per run instead. These are alternative request plans for the same work, not measured performance or evidence that a particular connector uses batching.

Include schema lookups, retries and requests made by other integrations when forecasting the workspace total. Check the actual endpoint and write outcomes; a batched request plan does not establish that the intended changes succeeded.

Estimate calls for your own workload

The supplied example runs twelve times on each of 22 active days: 264 runs. Five calls per run give 1,320 workflow calls. Adding 100 other workspace calls gives 1,420 planned calls, which is 420 above Free’s included monthly allowance.

Using individual updates would give 3,960 workflow calls and 4,060 including the same other traffic. With ten-record batching and eight runs per active day instead, the example becomes 980 total calls, leaving 20 within the Free allowance. These are calculated alternatives, not an instruction to reduce a required service frequency.

Why can a 429 happen at a low request rate?

The developer rate-limit reference specifies five requests per second per base, plus 50 per second across personal access token traffic from a given user or service account. Other integrations can share those budgets. After exceeding these rates, Airtable documents a 429 response and a 30-second wait before subsequent requests succeed.

The API troubleshooting guide distinguishes rate errors from a monthly billing-limit error. Check the error body, the actual base’s workspace and its usage. Requests can be below the per-second limit while the monthly allowance is already exceeded.

For monthly overages, the call-management guide describes a one-time 30-day Free grace period, followed by blocking over-limit calls until the calendar-month reset. Team processing slows to two requests per second after its allowance. The estimator does not know live usage, grace eligibility or current throttling; it checks planned monthly volume only.

How should I diagnose an integration failure?

Keep the HTTP status, error type, endpoint, base/workspace and request timing together. A 429 volume/rate issue needs a different investigation from an authentication or permissions failure. The troubleshooting guide also describes the limits on write operations for restricted viewers; buying extra call capacity does not change a user’s permission.

Review which process makes each request and its retry policy. After a rate-limit response, use the documented wait and backoff behaviour. Check whether a failed or interrupted write already took effect before designing a repeat operation, and reconcile the final records. The monthly estimator does not provide a request scheduler or execute retries.

A reduced polling frequency, caching or supported batching may change the call plan. Validate that the revised workflow still meets the required freshness and update behaviour. Keep integration-provider fees separate from the Airtable workspace offer.

Keep the forecast with the retained-plan review

The ledger gives the five example request types repeated across 264 runs, plus 100 other workspace calls. The blank review covers workspace identity, complete reads, writes/retries, shared rate budgets, monthly usage and retained costs. Actual usage, plan, results and evidence remain blank for your authorised evaluation.

No Airtable account, base, token, integration, API request, record update or subscription was operated for this guide. The files use an editorial planning format rather than Airtable’s API schema or a native export. For related workflow budgeting, see Zapier versus Make and the software total-cost checklist.

Frequently asked questions