List, search, create, update, upsert and delete Airtable records, read and edit base schemas, and comment on records from any Windmill script, flow or app.
Set up in 3 steps
Create a personal access token
At airtable.com/create/tokens, create a token and copy it (it starts with pat and is shown once). Add the bases it may reach and the scopes your scripts need: data.records:read and data.records:write for records, schema.bases:read for the base, table and field dropdowns, schema.bases:write to create or edit tables and fields, data.recordComments:read / :write for comments.
Add the resource in Windmill
Open Resources, add a resource of type airtable, and paste the token.
Run your first script
Fork any script below. Pick the base, then the table, from the dropdowns; they list what the token can reach.
Scripts
Building blocks, if none of the projects above fit. Fork one, run it, or call it as a step inside your own flow.
Upsert Records
Update Table
Update Multiple Records
Update Field
Update Comment
Search Records
List Tables (Get Base Schema)
List Comments
List Bases
Get Record or Create
Delete Multiple Records
Create Table
Create or Update Record
Create Field
Create Comment
Create Multiple Records
Delete Record
Get Record
Create Single Record
Update Record
List Records
Flows
Multi-step workflows that already wire Airtable to something else.
Trigger flows from Airtable
Airtable is not only a destination. These inbound paths are supported today.
Airtable webhooks on an HTTP route
Airtable can notify a URL when a base changes. Create the webhook through the API (POST /v0/bases/{baseId}/webhooks with a notificationUrl pointing at a Windmill HTTP route and a specification of what to watch; needs the webhook:manage scope). The notification is only a ping: the route's script then fetches the changes from /v0/bases/{baseId}/webhooks/{webhookId}/payloads, keeping the returned cursor between runs. A webhook made with a personal access token expires after 7 days unless it is refreshed (POST …/webhooks/{webhookId}/refresh), so schedule a refresh. The create response includes a macSecretBase64, shown only once, for authenticating the pings.
Resource types
The credential shapes the scripts on this page expect — pick the one your script asks for.
airtable
View raw schema →| Field | Type | Required | What it is |
|---|---|---|---|
| apiKey | string | No | Personal access token (starts with pat), created at https://airtable.com/create/tokens. Grant it the scopes and the bases your scripts need. |
airtable_table
View raw schema →| Field | Type | Required | What it is |
|---|---|---|---|
| baseId | string | No | |
| tableName | string | No |
Questions
The base or table dropdown is empty or errors
The dropdowns read the base schema, so the token needs the schema.bases:read scope, and it only lists the bases you added to the token. Edit the token in Airtable to grant both.
Can I connect with OAuth instead of a token?
Not yet. Airtable's OAuth requires PKCE, which Windmill's OAuth connections do not send, so the integration uses a personal access token.
What is the airtable_table resource for?
It pairs a base id with a table name and was the input of earlier versions of these scripts. The current scripts take the base and table as dropdowns instead; the resource type remains for flows that still use it.
How many records can I write at once?
Any number: the batch scripts send them 10 per request, the documented API limit. Batches are independent, so if one fails the earlier ones stay written. Airtable allows 5 requests per second per base and answers 429 beyond that.
Is my key stored on the hub?
Never. It lives only in your own Windmill workspace, encrypted at rest.