- Documentation
- Integrations
- Apps
- Airtable integration
Airtable integration
Read, write, and batch-edit records, manage comments and attachments, build bases, tables, fields and views, and react to record, field and table changes across your clients' Airtable bases.
What it does
The Airtable integration lets your agency operate on a client's bases without leaving TaskJuice. Connect a client's Airtable account once and your workflows can list and search records, read and write single rows, create or update up to 10 records in one batch call, upsert against matching columns, delete records, upload attachments, post, edit and delete record comments, inspect a base's full schema, list the bases and views the connection can reach, create and edit tables and fields, delete views, and identify the connected user. Ten change triggers start workflows when records are created, updated or deleted, when a form is submitted, and when fields or tables change — with exact change detail, including previous values and true deletions.
Connect an Airtable account
Airtable connections run on your agency's own OAuth client. The scopes on Airtable's consent screen come entirely from the scope checkboxes you tick on that client — there is no platform default set — so set up the client first, then connect.
Register an OAuth integration in Airtable
Create an OAuth integration in Airtable's builder hub to get a client ID and secret. Use the redirect URL that TaskJuice shows on the client form in the next step.
Add the client in TaskJuice
Open Apps → Airtable in your workspace and register the Airtable OAuth client with the client ID and secret from step 1.
Tick the scopes your workflows need
Check the scope boxes on the client form. The full catalog is
data.records:read,data.records:write,data.recordComments:read,data.recordComments:write,schema.bases:read,schema.bases:write,user.email:read,webhook:manage, andworkspacesAndBases:read. Checking fewer is fully supported and simply limits which actions and triggers your workflows can publish with.user.email:readis optional and only adds the email address toairtable/whoami's response. The ten change triggers needwebhook:manage,data.records:read, andschema.bases:readtogether. Register the same scopes on the Airtable side of the OAuth integration — Airtable refuses a consent that asks for a scope the registration does not declare, and it rejects the whole authorization request rather than the one scope.Connect
Go to Connections, choose Airtable, and click Connect. Sign in with the Airtable account that owns or has been invited to the bases you want to automate, and pick which bases the connection can access on the consent screen.
If a workflow uses an action whose required scope is not checked on your client, publishing is blocked with a validation error that names the missing scope — the workflow never fails at runtime with a permissions error you have to trace back. Check the named scope on the client, reconnect, and publish again.
To revoke access at any time, visit Airtable integrations and remove the entry, or delete the OAuth client from Airtable's page under Apps.
For the general connect flow, see Connect an account.
Triggers
Ten triggers watch a base for changes and start workflows with exact change detail read from Airtable's own change feed — true deletions, the previous values of edited fields, and form submissions told apart from ordinary inserts. Each trigger checks for changes on the workflow's poll schedule (default: every 5 minutes; configurable in the trigger's advanced settings), and the first check records a starting point without emitting anything, so changes that predate the workflow do not fire it.
Record triggers
| Trigger key | Fires when |
|---|---|
airtable/record-created | A record is added to the chosen table — from the Airtable app, an API call, an automation, or a sync. Form submissions are excluded and arrive via airtable/new-form-submission instead, so using both never double-fires. |
airtable/record-updated | Field values change on records in the chosen table. Each event carries the record's current values, the changed fields' previous values, and the changed field names. Optionally watch specific fields so only they fire. |
airtable/record-deleted | A record is deleted from the chosen table. |
airtable/new-form-submission | Someone submits an Airtable form that creates a record in the chosen table. Covers both Airtable form experiences — classic form views and the newer form builder — and can be narrowed to specific forms with the Forms field. |
Field and table triggers
| Trigger key | Fires when |
|---|---|
airtable/field-created | A field is added to a table in the chosen base. Optionally narrowed to one table. |
airtable/field-updated | A field's definition changes — a rename, for example — with the previous definition included. |
airtable/field-deleted | A field is removed from a table in the chosen base. |
airtable/table-created | A table is added to the chosen base. |
airtable/table-updated | A table's name or description changes, with the previous values included. |
airtable/table-deleted | A table is removed from the chosen base. |
Each poll cycle emits one activation carrying every change that fired in an items array. To process changes one at a time, drop a Loop node downstream and iterate over items; to act on the whole batch at once (a digest email, a bulk insert), skip the Loop and use the array directly.
Legacy polling triggers
airtable/new-record and airtable/updated-record are the original view-based polling triggers. They are deprecated: workflows already using them keep running unchanged, but they no longer appear when building a new workflow — the change triggers above see everything they saw, plus deletions, previous values and form submissions, without any view-ordering setup. They read the top 100 rows of a view you name by typing it into the View field, so detection is bounded to that ordered window. airtable/new-record fires only for records created after the workflow is first published, judged by the record's own creation date, so editing a record that existed before then does not fire it, even when the edit lifts it to the top of a last-modified view.
Actions
All 24 actions run against a connected Airtable account. Base and table fields are dropdowns backed by the connection, and so is the view field on airtable/search-records. airtable/list-records' View field is still typed by hand. Every field also accepts an expression so you can compute the value from an upstream node.
Records
| Action key | What it does |
|---|---|
airtable/list-records | Returns records from a table with optional view, field selection, single-key sort, formula filter, cell formatting, date-dependency metadata and continuation token. |
airtable/search-records | The POST form of List Records: the same parameters travel in the request body (Time Zone and User Locale stay on the query string, where Airtable's own client puts them), so long formulas, long field lists and multi-key sorts fit. |
airtable/get-record | Returns a single record by its Airtable record ID. |
airtable/create-record | Inserts a new record with a field map and an optional typecast flag. |
airtable/update-record | Patches the supplied fields on an existing record without touching the rest. |
airtable/delete-record | Removes a record from a table. |
airtable/upload-attachment | Uploads a base64 file (up to 5 MB decoded) into an attachment cell on a record. |
Sorting
airtable/list-records sorts on one field, because Airtable encodes sort keys positionally in the query string and TaskJuice pins the first position. When you need to order on two or more fields, use airtable/search-records — its request body carries the whole sort array, which is also Airtable's own answer to a query string that grows too long.
Batch operations
Each batch call accepts between 1 and 10 records — that is Airtable's per-request limit, and TaskJuice validates it before the step runs, so an oversized array fails the step with a clear validation error instead of a provider rejection.
| Action key | What it does |
|---|---|
airtable/create-records | Creates up to 10 records in one request. |
airtable/update-records | Patches up to 10 existing records in one request. |
airtable/upsert-records | Creates or updates up to 10 records, matching existing rows on 1 to 3 merge columns you name in fieldsToMergeOn. |
airtable/delete-records | Permanently deletes up to 10 records in one request. There is no undo through the API — deleted records are gone. |
Comments
| Action key | What it does |
|---|---|
airtable/create-comment | Adds a comment to a record, optionally as a threaded reply via parentCommentId. |
airtable/list-comments | Lists the comments on a record, paginated by Airtable's offset cursor. |
airtable/update-comment | Rewrites the text of a comment. Airtable only lets a comment's author edit it. |
airtable/delete-comment | Permanently removes a comment. There is no undo through the API. |
Schema, bases and views
| Action key | What it does |
|---|---|
airtable/get-base-schema | Reads the schema of every table in a base — table names, field types, and views. |
airtable/list-bases | Lists the bases the connection can reach, 1000 at a time, with each base's permission level. |
airtable/create-base | Creates a new base in a workspace. Copy the workspace ID from the Airtable UI — Airtable has no endpoint that lists workspaces. |
airtable/create-table | Creates a new table in an existing base; the first entry in fields becomes the primary field. |
airtable/update-table | Renames a table, rewrites its description, or updates its date-dependency settings. |
airtable/create-field | Adds a field (column) to a table, with the type-specific options Airtable documents for that field type. |
airtable/update-field | Renames a field, rewrites its description, or edits its options — the only three body fields Airtable accepts, so a field's type is not changed here. |
airtable/list-views | Lists the views in a base with their ids, names and types, optionally including each grid view's visible field IDs. |
Identity
| Action key | What it does |
|---|---|
airtable/whoami | Returns the connected Airtable user's id. Needs no scope at all; the response also carries the email address when the OAuth client requested user.email:read. |
Known limitations
- Each Airtable record list response returns at most 100 rows. Use the
offsetcontinuation token returned with the response to fetch the next page. - Airtable rate-limits each base to 5 requests per second per access token. When a 429 is returned, TaskJuice surfaces it as a retryable rate-limit error and respects the recommended backoff.
- The legacy view-based triggers see only the top 100 rows of the chosen view each poll; the ten change triggers read Airtable's change feed and have no such window.
- Batch actions accept at most 10 records per call, and
airtable/upsert-recordsmatches on 1 to 3 merge columns — Airtable's own per-request limits, enforced before the step runs. - The change triggers need the connected account to have creator access on the base being watched — Airtable only lets base creators register for change tracking. Ask the base owner for creator access, or connect an account that has it.