Airtable Trigger
Triggers a workflow on Airtable webhook deliveries (data changes, schema changes) for a single base. Webhooks are automatically registered with Airtable on publish.
Requires an Airtable connection.
Configuration
| Field | Description | Notes |
|---|---|---|
| Connection | Airtable connection | Required |
| Base ID | The Airtable base to watch (e.g., appXXXXXXXXXXXXXX) | Required. Find in airtable.com → Help → API documentation |
| Change Types | What kind of changes fire the webhook | Table Data / Metadata / Fields |
Output
| Field | Description |
|---|---|
body.base.id | The Airtable base ID |
body.webhook.id | The webhook subscription that fired |
body.timestamp | Time of the change |
headers.X-Airtable-Content-MAC | HMAC signature (already verified before the workflow runs) |
Pulling Payloads
Airtable webhooks deliver a change ping rather than the full payload. To fetch what changed, use the Airtable List Payloads API endpoint with the webhook.id from the body — typically via the HTTP node downstream of the trigger.
How It Works
- On publish, the backend calls Airtable's Create Webhook endpoint with the base ID, your workflow's public URL, and the configured
dataTypesfilter. - Airtable returns a
macSecretBase64— the backend stores this and uses it to verify theX-Airtable-Content-MACheader on every delivery (HMAC-SHA256 hex digest of the raw body). - On unpublish/delete the webhook is deleted from the base.
Caveats
- Airtable webhooks expire after 7 days of no activity. Re-publish the workflow to refresh.
- An Airtable base can have at most 10 webhooks. Reuse triggers across workflows when possible.