Airtable Trigger
The Airtable Trigger fires your workflow when a record event happens in an Airtable table — record.created, record.updated, or record.deleted. It supports two modes:
- Instant — Airtable POSTs a webhook to InditeAI the moment the event happens. Real-time, but requires Airtable's Team plan or higher (because the Send a webhook / Run a script automation actions are only available on Team+).
- Polling — InditeAI checks Airtable on a schedule and fires the workflow when changes are detected. Works on every Airtable plan, including Free, with no Airtable automation needed.
You pick the mode in the trigger settings panel.
Mode 1: Instant (webhook)
Plan requirement
You need:
- Airtable Team plan or higher — required for the Send a webhook (or Run a script) automation action.
- InditeAI account — Free tier is fine.
If you are below the Team plan in Airtable, skip to Mode 2: Polling.
Setup
Step 1: Configure the trigger
- Add the Airtable Trigger block as your workflow's trigger.
- Set Trigger mode to Instant (webhook).
- Select or create your Airtable Credentials (a Personal Access Token).
- Enter your Base ID (e.g.,
appXXXXXXXXXXXXXX) and the Table name or ID. - (Optional) Enter a Webhook Tag to label this subscription.
- Choose the events you want to subscribe to (
record.created,record.updated,record.deleted). - (Optional) Set a Response variable name to store the incoming payload as a workflow variable for downstream blocks.
- Save the workflow. Copy the Webhook URL that appears — it follows the pattern
https://<your-domain>/api/airtable/webhook/<workflowId>.
Step 2: Send webhooks from Airtable
In your Airtable base:
-
Open Automations → Create automation.
-
Pick a trigger that matches the event you subscribed to:
- For
record.created→ When a record is created. - For
record.updated→ When a record matches conditions or When a record is updated. - For
record.deleted→ use a Last modified / status-flag pattern (Airtable does not expose a native "record deleted" trigger; many users implement a soft-delete field instead — or use Mode 2: Polling, which detects deletes natively).
- For
-
Configure the trigger to watch the correct table, then click Test trigger so Airtable captures a sample.
-
Click + Add advanced logic or action → choose either:
- Send a webhook (simpler, Team+), or
- Run a script (more flexible, also Team+).
-
Configure the action:
Send a webhook:
-
URL: paste the Webhook URL from Step 1.
-
Method:
POST. -
Headers:
Content-Type: application/json. -
Body (JSON, with
event_typematching your subscription):{ "event_type": "record.created", "base": { "id": "appXXXXXXXXXXXXXX" }, "table": { "id": "tblXXXXXXXXXXXXXX", "name": "Leads" }, "record": { "id": "recXXXXXXXXXXXXXX", "fields": { /* insert the fields from the trigger step */ } }, "timestamp": "{{now}}" }
Run a script (alternative):
const config = input.config() await fetch("https://<your-domain>/api/airtable/webhook/<workflowId>", { method: "POST", headers: { "Content-Type": "application/json" }, body: JSON.stringify({ event_type: "record.created", base: { id: config.baseId }, table: { id: config.tableId, name: config.tableName }, record: { id: config.recordId, fields: config.fields }, timestamp: new Date().toISOString(), }), }) -
-
Click Test action, then Turn on the automation.
-
Back in InditeAI, click Mark as registered in the trigger settings.
The event_type value must match exactly (record.created, record.updated, or record.deleted). Events with a missing or non-matching event_type are silently skipped (200 OK with processed: 0).
Webhook signature verification (instant mode)
InditeAI optionally verifies an X-Airtable-Content-MAC header using HMAC-SHA256, with the linked credential's API key as the secret:
X-Airtable-Content-MAC: hmac-sha256=<sha256_hex(rawBody, apiKey)>- If no
X-Airtable-Content-MACheader is sent, the request is accepted (default for Automations-based webhooks). - If the header is sent, it must match — otherwise the request is rejected with
403.
This makes it safe to use a self-managed forwarder that signs the payload (e.g., a Cloudflare Worker around Airtable's Webhooks API).
Mode 2: Polling
Polling runs entirely inside InditeAI — there is no Airtable-side automation to configure. InditeAI uses your Airtable credentials to list records on the interval you choose, compares them against the previous snapshot, and fires the workflow when records are created, updated, or deleted.
Plan requirement
- Airtable: any plan — Free, Plus, Pro, Team, Business, Enterprise. Polling only requires API access via a Personal Access Token, which is available on every plan.
- InditeAI: any plan that supports active workflows.
Setup
- Add the Airtable Trigger block as your workflow's trigger.
- Set Trigger mode to Polling (any plan).
- Select or create your Airtable Credentials (a Personal Access Token with
data.records:readscope on the target base). - Enter your Base ID (e.g.,
appXXXXXXXXXXXXXX) and the Table name or ID. - Choose the events you want to fire on (
record.created,record.updated,record.deleted). - (Optional) Set a Response variable name.
- Open the Checking Interval section and pick how often InditeAI should poll:
- Every X minutes — fastest cadence (minimum 1 minute).
- Hourly — every hour at minute 0.
- Daily / Weekly / Monthly — at a specific hour and day.
- Custom (cron) — full cron expression, e.g.
*/15 * * * *.
- Save and publish the workflow. The polling job starts automatically when the workflow is activated and stops when it is deactivated.
How polling detects changes
On each poll, InditeAI fetches all records in the configured table (paginated up to 1000 records per poll, 100 per page) and compares them against the snapshot saved in workflowTriggerState for this workflow:
| Comparison vs. previous snapshot | Emits event |
|---|---|
| Record ID present now, missing before | record.created |
| Record ID present in both, but field hash differs | record.updated (with changedFields populated) |
| Record ID missing now, present before | record.deleted |
The first poll after enabling the trigger establishes the baseline snapshot — it does not fire record.created events for every existing row. Only subsequent polls produce events.
Polling considerations
- Minimum interval: 1 minute. Faster polling burns Airtable's per-base API rate limit (5 requests/second).
- Page limit per poll: up to 1000 records (10 pages × 100). If your table is larger, you may miss changes outside that window — split the table or use a filtered view.
- One execution per poll: if multiple records change between two polls, all matched events are bundled into a single workflow execution, with the events array passed as the trigger payload.
- Deletion latency: polling is the only way to reliably detect deletions; Airtable's Automations don't expose a native delete trigger.
- Plan limits: each fired execution counts against your InditeAI workspace's monthly execution limit, regardless of how many events were bundled.
Supported Event Types
| Event | Description | Available in instant | Available in polling |
|---|---|---|---|
record.created | A new record was inserted into the table | Yes | Yes |
record.updated | One or more fields on an existing record changed | Yes | Yes |
record.deleted | A record was removed | Yes (manual setup) | Yes (native) |
You can subscribe to multiple events in a single trigger block.
Response Data
When the trigger fires, the payload is exposed to the workflow. Common fields:
| Variable | Description |
|---|---|
event_type | The event (record.created, record.updated, record.deleted) |
base.id | The Airtable base ID |
table.id / table.name | The table the record belongs to |
record.id | The Airtable record ID (e.g., recXXXXXXXXXXXXXX) |
record.fields | An object containing the record's field values |
changedFields | (update events only) Array of field names that changed |
previousFields | (polling update events) The field values from the previous snapshot |
timestamp | When the event was detected |
If you set a Response variable name (e.g., airtableEvent), the entire payload is also stored as airtable_airtableEvent for downstream blocks.
Example Use Cases
- Lead capture: When a new row is added to a Leads table, route the lead to a sales rep, send a welcome email, and create a deal in your CRM.
- Status sync: When a record's Status field changes to
Approved, trigger a downstream system update or post to Slack. - Content publishing: When a Blog post record flips to
Published, push to your CMS or social channels. - Inventory alerts: When stock quantity drops below a threshold, kick off a reorder workflow.
- Cleanup audits: Use polling to detect deleted records and log them to a backup table or alert a human.
Troubleshooting
Workflow not firing (instant mode)
- Confirm the Airtable Automation is On.
- Ensure the workflow is Published and Active in InditeAI.
- Verify the Webhook URL in Airtable matches what is shown in the trigger settings, including the workflow ID.
- Check that the
event_typefield in the webhook body is one ofrecord.created,record.updated,record.deleted.
Workflow not firing (polling mode)
- Make sure the workflow is Active — polling jobs only run for active workflows.
- Check the credential has
data.records:readscope on the target base. - Confirm the Base ID and Table match exactly (table name is case-sensitive).
- Wait at least one full interval after enabling — the first poll only establishes the baseline snapshot and does not fire events for pre-existing rows.
200 OK but processed: 0 (instant mode)
- The request reached InditeAI, but its
event_typedid not match a subscribed event. Add the event in the trigger settings or fix the value sent by Airtable.
403 Airtable signature verification failed (instant mode)
- An
X-Airtable-Content-MACheader was sent, but it did not match an HMAC-SHA256 of the raw body using the linked credential's API key. Either remove the header or align the signing secret on the sender side.
Airtable API 401/403 errors (polling mode)
- The Personal Access Token is missing scopes or doesn't have access to the base. Re-create the token with
data.records:readand the specific base added under "Access".
Polling missed updates / changes look "double"
- The previous snapshot is keyed by
workflowId. Switching the Base ID or Table without disabling and re-enabling the workflow can produce a burst ofrecord.created/record.deletedevents. Toggle the workflow off and on after changing those fields.
429 Too Many Requests
- Workspace execution limit reached. Upgrade the plan or wait for the limit window to reset.