Airtable API: complete Web API guide in 2026

What is the Airtable API used for?

When we talk about the "Airtable API," we are usually referring to the Web API.

It allows a system outside of Airtable to interact with your bases in a programmed way.

An application can notably:

• read records;

• create new records;

• modify existing data;

• delete records;

• filter and sort retrieved data;

• consult the structure of a base;

• work with multiple records in a single request.

Let's look at a simple example.

A company manages its delivery in Airtable but has a client application developed separately. When a client opens their portal, the application can query Airtable to retrieve their projects, their statuses, and the next deliverables to display.

The logic is then:

Application → Airtable Web API → base data

The API becomes the interface between Airtable and the rest of the system.

This role must be distinguished from that of the Webhooks API.

The Web API allows reading or modifying Airtable. The Webhooks API allows an application to be notified when a change occurs in Airtable.

Both can therefore be complementary. We detail this distinction in our guide on Airtable webhooks.

API, Automation, webhook or Make/n8n: which to choose?

Before creating an API integration, the first question is not "how to call Airtable?", but where should the process live?

This distinction avoids many unnecessarily complex architectures.

Imagine, for example, that a project status changes to "To invoice" in Airtable and a draft needs to be created in invoicing software.

It would be possible to build:

Airtable → external system → Airtable API → invoicing software API

But if Airtable already knows how to detect the change, a much more direct architecture may suffice:

Airtable Automation → Run a script → invoicing software API

The Airtable Web API is therefore not necessary simply because an external API is involved in the workflow.

This is also the principle we detail in our guide to Airtable automations: keep the process in Airtable when it can be executed properly there, then add technical layers only when they address a real constraint.

How does the Airtable Web API work?

The Web API follows a classic REST architecture.

An application sends a request to Airtable. This request specifies, among other things:

• the base and table concerned;

• the desired action;

• the authorizations used;

• possibly the data to create or modify.

Airtable then processes the request and returns a response in JSON format.

The main operations correspond to the usual HTTP methods:

GET allows retrieving data.

POST notably allows creating records.

PATCH allows modifying existing records.

DELETE allows deleting them.

It is therefore not necessary to use a specific Airtable connector to integrate the platform with an application. Any environment capable of making HTTP requests can theoretically communicate with the Web API.

Filter rather than retrieve everything

A common mistake is to retrieve an entire table and then filter the data in the application.

The Web API notably allows limiting the returned fields, sorting the results, using an existing view, or applying a filterByFormula.

If an application only needs a client's active projects, it is better to request this data directly from Airtable than to needlessly download thousands of records.

This logic becomes important for performance but also to limit the number of API requests.

Understanding pagination

A request to list records does not automatically return an entire table.

Airtable returns results in pages that can contain up to 100 records.

A table of 450 records will therefore require multiple requests to be fully retrieved.

The API provides an offset allowing to request the next page until there are no more.

This constraint seems minor during an initial test on ten records, but must be integrated from the start when an application needs to traverse larger volumes.

Using batch operations

For creations, modifications, or deletions, Airtable allows processing up to 10 records per request.

Modifying 500 records therefore does not necessarily need to generate 500 API calls.

There are also mechanisms like performUpsert, which allow searching for and then creating or updating a record in a single operation.

For large one-way imports, the classic Web API is not always the best solution: the Sync API notably allows sending CSV data up to 10,000 lines per request.

The goal is not to systematically use the same API, but to choose the mechanism that corresponds to the process.

How to authenticate an Airtable integration?

The old Airtable API keys no longer work since February 2024.

Two approaches are particularly important today.

Personal Access Token for an internal integration

The Personal Access Token, or PAT, is suitable when an integration is used for yourself, your business, or a controlled client environment.

When creating it, you define:

• the permissions granted to the token;

• the bases or workspaces it can access.

A system that only needs to read a base therefore has no reason to receive modification rights on all the bases in the workspace.

This is a major improvement compared to the old API keys.

The principle to remember is simple:

give an integration only the access it actually needs.

A PAT must obviously remain server-side or in a secure system. It must never be embedded directly into JavaScript executed in a user's browser.

OAuth for an application used by multiple clients

If you are developing an application that allows different users to connect their own Airtable account, using your own PAT is not the right architecture.

Airtable provides OAuth for this type of integration.

Each user can then explicitly authorize the application to access the necessary resources.

The difference is important:

Internal or controlled integration → PAT

Product or integration used by different Airtable accounts → OAuth

On Enterprise Scale, organizations can also use service accounts so that a critical integration does not depend on a collaborator's personal account.

4 cases where the Airtable API actually adds value

1. Building an application on top of Airtable

Airtable can serve as the data and administration layer while users work in a separately developed application.

For example:

Airtable → internal data and operations

Web application → user experience

The application can use the Web API to retrieve or modify the necessary information.

This architecture can be relevant for a very specific business tool or when the user experience needs to exceed what Airtable Interfaces and Portals allow.

However, it adds a real application layer to maintain.

Before developing a frontend, we therefore generally check if an Airtable Interface or portal does not already meet the need correctly. Our guide on creating a client portal with Airtable presents the different possible approaches before moving to custom development.

2. Connecting a business application to Airtable

An internal application may need to regularly send information to Airtable.

Imagine, for example, a tool that generates specific estimates or analyses.

Once the processing is finished:

Business application → Web API → Airtable record update

The application already possesses the business logic. The API simply serves to flow the data to Airtable.

3. Reading Airtable data from another system

An application can also use Airtable as a data source.

A reporting system, an internal tool, or a client application can, for example, retrieve only the records and fields it needs.

In this type of architecture, however, one must ask how often the data needs to be updated.

If the application queries Airtable every few seconds just to know if something has changed, the Webhooks API may make more sense than continuous polling.

Our guide to Airtable webhooks details this distinction precisely and explains when to associate Webhooks API and Web API.

4. Building an integration that needs to be fully controlled

Make or n8n simplify many integrations and remain perfectly suited to many workflows.

A direct integration via API becomes interesting when the application requires more control over:

• business logic;

• error handling;

• performance;

• retries;

• authentication;

• logging;

• user experience.

But "more control" also means more technical responsibilities.

A custom API integration is therefore not automatically more robust than a well-designed Make scenario.

It only becomes so if the architecture, the code, and its operation are themselves properly maintained.

When not to use the Airtable API?

This is probably the most important point of this guide.

If an Airtable Automation is enough

A status changes and you need to:

• create a record;

• update data;

• send a notification;

• generate a task;

• execute a simple logic.

Generally, start with an Airtable Automation.

Adding an external application solely to modify another Airtable table increases the number of components without necessarily improving the system.

To understand how far to go with native features before adding an external layer, consult our complete guide to Airtable automation.

If Airtable simply needs to call an external API

An Automation can execute a script and make an HTTP request to another API.

For a simple flow like:

Project validated → creation of a draft invoice

an Automation + Run a script can be more maintainable than a full external infrastructure.

If Make or n8n make orchestration simpler

Conversely, wanting to code everything directly is not always a good decision.

When five applications need to exchange data, with multiple branches and intermediate processing, an orchestration platform can offer better visibility than a set of scattered hosted functions.

The right choice is not the most technical one.

It is the one that the team will be able to understand, supervise, and maintain in two years.

What are the limitations of the Airtable API?

The Web API is performant enough for many business tools, but Airtable is not designed as an application database without limits.

5 requests per second per base

Airtable currently applies a limit of 5 requests per second for each base, regardless of the plan.

An integration that exceeds this limit receives a 429 error.

A reliable architecture must therefore plan for:

• limiting the number of calls;

• batch operations;

• suitable retries;

• possibly caching for frequent reads.

Airtable also applies a limit of 50 requests per second for all traffic using Personal Access Tokens from the same user or service account. If the limit is exceeded, Airtable indicates that you must wait 30 seconds before resuming requests.

Quotas that depend on the plan

In addition to the limit per second, some plans have a monthly quota.

At the time of this update:

Limits per second continue to apply on Business and Enterprise Scale.

For an integration called several thousand times each day, these quotas must therefore be part of the choice of plan and architecture.

Airtable keeps values up to date in its official documentation on Web API limits.

Airtable should not become a default backend

Being able to build an application on Airtable does not mean Airtable is the best database for any application.

When you need very large volumes, heavy traffic, complex transactional processing, or strong performance constraints, a dedicated application database may be more suitable.

Airtable can then remain useful as an operational tool or internal interface without being placed at the center of the entire technical architecture.

This is an important compromise: leverage Airtable's flexibility as long as it truly simplifies the system, then change architecture when constraints exceed what the platform is designed for.

How to start cleanly with the Airtable API?

We recommend not starting by creating a token.

Start by drawing the flow.

For example:

Application → Airtable

or:

Airtable → application

or even:

Airtable ↔ application

Then ask yourself who triggers the process, what data needs to flow, and at what frequency.

This often reveals that a Web API is not necessary — or conversely that it is precisely the right interface between the two systems.

Once the architecture is validated:

1. create the suitable authentication method;

2. limit the scopes and accessible resources;

3. identify the bases, tables, and fields actually needed;

4. first test a read and a write on a controlled environment;

5. manage pagination, errors, and limits before processing large volumes;

6. add logs to understand what happened in case of failure;

7. make sensitive operations idempotent to avoid duplicates during a retry.

The goal is not simply to get a first 200 response.

A professional integration must also continue to function properly when the API slows down, data is missing, a token changes, or a request fails.

Need to connect Airtable to your other tools?

HyperOps designs and evolves Airtable systems connected to other company tools: native automations, scripts, APIs, webhooks, and external architectures when the need justifies it.

We start from the process and data flow to choose the simplest architecture capable of working sustainably — without adding Make, n8n, or custom development when Airtable can already correctly execute the workflow.

Discover our Airtable support.

Frequently Asked Questions about the Airtable API