Airtable n8n templates

Airtable has a first-party n8n node covering search, create, update, upsert and delete, plus an Airtable Trigger that polls a table for new or changed records. Almost every Airtable automation is some arrangement of: trigger, search for a matching record, transform fields with a Set or Code node, then update or upsert.

The Airtable Trigger polls - it does not receive a push - so its interval is the floor on how quickly the workflow reacts. Set it to the slowest interval you can tolerate; polling every minute across several workflows is the quickest way to hit Airtable's rate limit.

Airtable retired user-level API keys in early 2024. Use a Personal Access Token created at airtable.com/create/tokens, and scope it to the specific bases the workflow touches rather than all of them.

Grant only the scopes you need: data.records:read for anything that only queries, plus data.records:write to create or update, plus schema.bases:read if you want n8n to populate the table and field dropdowns instead of making you type IDs. A token missing schema.bases:read still works, but every field selector turns into a manual ID entry and the workflow becomes far harder to read later.

Reference tables by ID (tblXXXXXXXX), not by name, in anything you intend to keep. Renaming a table in Airtable's UI is a one-click action that silently breaks every workflow referencing it by name.

Airtable allows 5 requests per second per base. Exceed it and the API returns 429 and then locks that base out for 30 seconds - long enough that a single burst can fail an entire run.

The fix is batching, not retrying. Airtable's create and update endpoints accept 10 records per call, so a Loop Over Items node with a batch size of 10 turns 500 single-record writes into 50 calls. Add a short wait between batches - one second is plenty - and set the Airtable node's 'Retry On Fail' so an occasional 429 recovers instead of failing the execution.

If several workflows write to the same base, the limit is shared across all of them. Two workflows that each stay comfortably under the ceiling alone will still trip it when they run at the same minute of the hour, so stagger their schedules.

Most Airtable errors in n8n are type mismatches rather than connection problems. A Single Select rejects any value that is not already one of its options unless the token has schema write permission and typecast is enabled. A Linked Record field expects an array of record IDs, not names - so you look the linked record up first and pass its ID. A Date field wants ISO 8601; a date rendered as DD/MM/YYYY is accepted as a string by the API and then read back wrong.

Attachment fields take an array of objects with a url property, and Airtable fetches that URL itself - which means the URL has to be publicly reachable. A signed link that expires in five minutes will sometimes work and sometimes not, depending on how busy Airtable is.

Computed fields - formulas, rollups, autonumber, created time - are read-only. Including one in an update payload fails the whole record, so strip them in a Set node before the write.

Airtable is often the easiest place to park data an automation produces - scraped rows, form submissions, AI-generated summaries - because it is legible to non-technical colleagues in a way a Postgres table is not.

Use the upsert operation with a column you control as the match key (an external ID, a URL, an email address) rather than create, so re-running a workflow corrects records instead of duplicating them. A base with a unique-ish key column and upsert on every write is effectively idempotent, which is what you want when a run half-fails and you need to run it again.