API integration for Airtable
We build your Airtable connector
We wire Airtable into your product as a temporary back office: the business enters orders, ops filters them, and “shipped” status flows back into your app.
- Senior product team
- Airtable connectors in production
- from scoping to monitoring
What role does Airtable play in an information system and when should you integrate it?
Airtable is an online collaborative database that business teams build themselves, without developers. It serves as a temporary system of record for workflows that have not yet found their place in a dedicated tool: candidate tracking, product catalogue, editorial project management. You build an Airtable integration when this base becomes the source of truth for a process and other tools: CRM, ERP, business application, need to read from or write to it automatically, without teams entering the same information twice.
What our clients build on the Airtable API
Today's parcels grid fed by the ERP
Ops filters in Airtable, the webhook brings back Shipped. The spreadsheet is no longer a dead export.
Internal form into the software
Shipped status comes back into your system. The record updates, without a second parallel process.
Light catalogue read by the site
Edited in Airtable, read through a cache. 5 req/s forbid live on every page view.
Transitional CRM before HubSpot
One-way sync, pinned IDs. Airtable holds the MVP, not production at 100,000 calls/month on a Team plan.
What this changes in your production
Engineering in service of a measurable result: a back office in weeks, IDs that hold, a 5 req/s that no longer surprises.
Ops works in the grid, not in an export
The ERP pushes orders. Truth stays in the product; Airtable is the operational view.
The record updates without retyping
Shipped status comes back into your application. No second process between the grid and the system of record.
The site stays fast while the team edits
The catalogue is read through a cache, not live on every visit. The team can edit Airtable without breaking the front.
Airtable stays replaceable
Business identifiers are pinned on the product side. The day the process matures, you switch without rebuilding the system.
How we ship your Airtable connector
Scoping
Which bases, PAT or OAuth, Team plan (100,000 calls/month) or Business. Scopes and resources bounded to the useful base.
IDs
Table IDs, matching field record id ↔ business id. Table names are not keys.
Development
Client rate limiter < 5/s/base, 429 = sleep 30 s, read cache, webhook refresh < 7 days.
Monitoring
429s, disabled webhooks, Team monthly quota. Alert before the cut, not after an empty grid.
What the Airtable API allows
- Records per base and per table
- Create, read, update, list. Bearer auth, data.records:write scopes, grantor must be editor, base in the token resources.
- Webhooks ping then pull
- The POST does not contain the record. You must list payloads, so you consume the 5/s quota. This is not Stripe.
- 5 req/s, 30-second penalty
- Per base, plus 50 req/s across bases for PATs of one user. Airtable reserves the right to change limits, including by plan.
- 7-day expiry
- PAT/OAuth: refresh or list payloads extends 7 days. Max 10 webhooks per base, 2 per base per OAuth integration.
Airtable API vocabulary
- 5 req/s
- Per base. A 429 requires waiting 30 seconds, not 1 s. A burst of 20 calls costs a half-minute stop. The queue must anticipate the 5/s.
- Ping + pull
- The webhook notification does not carry the record. You must GET payloads, so you consume the 5/s a second time. This is not a Stripe event.
- 7 days
- PAT/OAuth webhook expiry. refresh or list payloads resets 7 days. A forgotten webhook dies silently. Job and disabled alert.
- 2 OAuth webhooks / base
- A Marketplace app does not place one webhook per table at will. 10 webhooks max per base across all regimes.
- Table ID
- The table name changes, the ID does not. Pin IDs in configuration. A connector keyed on the label breaks on the first ops rename.
- PAT
- Personal Access Token, tied to the user. An employee leaving breaks the integration. Service account or OAuth for the client. Query api_key: dead on 1 February 2024.
The real constraints of the Airtable API
The Airtable 429 lasts 30 seconds
It is not a retry in 1 s. A poorly paced burst stops the whole base for half a minute. The client-side limiter anticipates the 5/s, it does not only react.
The webhook is a ping, not a payload
You must list payloads, so more 5/s. Designing the handler like Stripe (everything in the POST) produces mute syncs or cascading 429s.
7 days, otherwise silence
Refresh mandatory, alert if disabled. 2 OAuth webhooks per base: an app does not multiply by table. This is an app constraint, not a spreadsheet one.
Team 100k, Business without monthly cap
Business does not remove the 5/s. A 1/min poll × N tables burns Team. User-facing live always goes through a cache, or the grid freezes on the first 429.
Airtable PAT or OAuth / service account?
Two access regimes. The PAT is fast in staging. In production at the client, an employee leaving must not cut the connector.
| Criterion | PATUser | OAuthApp / service |
|---|---|---|
| Time to first call | A few minutes | App, scopes, resources |
| Who holds the token | An employee | The integration |
| Employee leaving | The connector breaks | No effect |
| Webhooks / base | Up to 10 | 2 per OAuth integration |
| 50 req/s across bases | Yes, per user | Depends on the app account |
| api_key in query | Dead since 01/02/2024 | Never the model |
| The right case | Internal script, staging | Product, client, Marketplace |
The grantor must be an editor, the token data.records:write, the base in the resources. Three conditions, not one. We bound scopes to the useful base, not all workspaces.
What we measure on an Airtable integration
The other productivity tools
Airtable is combined more often than it is replaced. These options are discussed at scoping.
We combine Airtable with
The stack around Airtable on our projects.
Airtable: your questions
Four steps. Bearer auth (PAT in staging, OAuth or service account in prod), no more api_key in query since 1 February 2024. Pin table IDs and a matching field. Put a client rate limiter under 5 req/s per base, with sleep 30 s on 429. Webhooks: ping then list payloads, refresh before 7 days, 2 OAuth webhooks max per base. The sensitive part is not POST records, it is the queue, the read cache and the refresh job.
That is the public contract: 5 req/s per base, 50 req/s across bases for PATs / service accounts of the same user. A 429 requires waiting 30 seconds. A burst of 20 calls costs a half-minute stop on the base. Team adds 100,000 calls/month per workspace; Business removes that cap, not the 5/s. A screen that reads Airtable live needs a cache. The queue anticipates the 5/s, it does not only react to the 429.
This is not Stripe. The notification is a ping. Diffs are pulled with list payloads, so more 5/s. 7-day expiry (PAT/OAuth): refresh or list payloads resets 7 days. Max 10 webhooks per base, 2 per base per OAuth integration. A forgotten webhook dies silently (disabled). We put the refresh job, the alert, and we do not design a Marketplace app with one webhook per table. Ping plus pull is the contract, not a preference.
No. End of deprecation on 1 February 2024. A connector that passes api_key in query is already dead. Current auth: Authorization Bearer, PAT or OAuth, scopes and resources (bases / workspaces) configured on the token. To write: grantor editor, data.records:write scope, base in the resources. Three conditions. A PAT tied to an employee is not a client connector, and we replace it before production.
A first useful flow, pushing orders to a grid and bringing a status back, ships in two to three weeks. A full chain (several tables, webhooks, site cache, OAuth) is closer to six to eight weeks. Duration depends on ID mapping, the plan (Team 100k) and real volume under 5/s. We scope the perimeter up front and give you a firm estimate before we start, including the monthly call budget.
An Airtable integration project?
Let's talk. 30 minutes to scope the bases, the 5 req/s, and tell you frankly whether Airtable holds the volume, or whether the system of record already belongs elsewhere.
Discuss my Airtable project