Airtable, in every client’s workflows.

Create a record, find records, or start when a record is added, with the client’s own Airtable account.

Triggers: 2start a workflow
Actions: 3steps in a workflow

Start a workflow when something happens in AirtableBeta

By webhook where Airtable sends one, by checking where it does not. A webhook is checked once a day to see it is still on, and if Airtable turns it off the alert carries a Reconnect button.

A record is addedPolledA new row in a table, checked every 15 minutes. The token needs data.records:read.
A record is changedPolledA row edited in a table, checked every 15 minutes; optionally only rows in a view (“A record enters Ready to quote”). Airtable says when a row changed only through a field: add a “Last modified time” field to the table (limit it to the columns that matter) and name it here. The token needs data.records:read.

Do it in Airtable

A step with its own fields: values from the run go in by name, and what Airtable answers is there for the next step.

Create a recordAdd one row to a table. Field names must match the table’s columns.
Find recordsEvery matching record, up to 1,000 (ten pages of 100). Past that, the step says it stopped and Airtable’s offset is kept. Nothing found is an empty records list.
Update a recordChange fields of one record, found by its id. Fields left out keep their value.

Connect the client’s Airtable

On the client’s page in Thrum: Add credential, type Airtable personal access token.

airtable.com/create/tokens → Create token → scopes data.records:write and data.records:read (lookups and the triggers) → add the client’s base → copy the token.

The key is stored encrypted and bound to that client: another client’s workflow cannot use it, and no template or pack copies it.

Airtable’s API documentation

Via HTTP

Or by web request: add a record to a table

Every lead lands as a row in the base the client already runs their business from. The web request step, filled in: paste it, swap in the client’s ids, add their key.

01
Add the client’s credential
On the client’s page in Thrum: Add credential, type API key. airtable.com/create/tokens → Create token → scope data.records:write → add the client’s base → copy the token.
```
{
  "api_key": "pat…"
}
```
02
Add a web request step
Name it “Add to Airtable”, set it as here, and pick the credential. Values in double braces are read from the run: here, the lead the form brought in.
BASE_ID
The part of the base’s address that starts with app: airtable.com/appXXXXXXXXXXXXXX/….
TABLE_NAME
The table’s name (spaces as %20) or its id, which starts with tbl.
Name, Email, Phone, Request
Each key in fields is a column name in the table, spelled exactly.
```
{
  "method": "POST",
  "url": "https://api.airtable.com/v0/BASE_ID/TABLE_NAME",
  "headers": {
    "Authorization": "Bearer {{ credential.api_key }}"
  },
  "body": {
    "fields": {
      "Name": "{{ lead.name }}",
      "Email": "{{ lead.email }}",
      "Phone": "{{ lead.phone }}",
      "Request": "{{ lead.summary }}"
    },
    "typecast": true
  }
}
```

What goes out, and what comes back

`typecast: true` lets Airtable turn text into a select option or a date; without it a value that does not fit the column is refused.

POST https://api.airtable.com/v0/BASE_ID/TABLE_NAME
content-type: application/json
authorization: Bearer ••••••••

{
  "fields": {
    "Name": "Nadia Karim",
    "Email": "nadia@example.com",
    "Phone": "+447700900222",
    "Request": "Quote for a new bathroom, two basins and a shower"
  },
  "typecast": true
}

200
{
  "id": "rec8hT2kQ9xLmW1",
  "createdTime": "2026-09-28T09:05:01.000Z",
  "fields": {
    "Name": "Nadia Karim",
    "Email": "nadia@example.com",
    "Phone": "+447700900222",
    "Request": "Quote for a new bathroom, two basins and a shower"
  }
}

Watched like everything else

When Airtable stops answering or refuses the client’s key, you hear about it, and your client does not.

A failing request: Tried 3 times, 5 seconds apart and doubling, only for errors a retry can fix
A service that asks for a pause: Given it, up to an hour
Requests at once, per account: 2, per worker; the rest wait their turn
Timeout: 15 seconds, unless the step sets its own
Private and internal addresses: Refused, on every redirect too
The client’s key: Encrypted, bound to the client, and kept out of every run record
A step that keeps failing: Marks the workflow Degraded and alerts you, not the client