Skip to main content

Airtable Component

Manage records, tables, and bases in Airtable.

Component key: airtable ·
· Changelog ↓

Description​

Airtable is a spreadsheet-database hybrid, with the features of a database but applied to a spreadsheet. This component allows listing, creating, deleting, and updating records in an Airtable Base.

API Documentation​

This component was built using the Airtable Web API.

Airtable developer documentation can be found here.

Connections​

API Key and Base ID (Deprecated)​

key: apiKey

Deprecation Notice​

Airtable API keys have been deprecated as of February 1, 2024.

Use OAuth 2.0 or personal access tokens instead for all new integrations.

InputNotesExample
API Key

You can generate an API key from https://airtable.com/account.

keyvTlNCTqEXAMPLE
Airtable Base ID

Visit https://airtable.com/api and select your workspace. The ID of your base will be printed for you in green.

appLkNDICXNqxSDhG

OAuth 2.0​

key: oauth

To create an Airtable OAuth 2.0 connection, an OAuth integration must be registered in Airtable.

Prerequisites​

  • An Airtable account with permissions to create OAuth integrations

Setup Steps​

  1. Log in to Airtable and navigate to airtable.com/create/oauth.
  2. Click Register new OAuth integration.
  3. Fill in the required fields:
    • App name: A descriptive name for the integration
    • App description: Brief description of the integration's purpose
    • Redirect URLs: Enter https://oauth2.prismatic.io/callback as the OAuth redirect URL
  4. Under Scopes, select the scopes required for the integration. Refer to Airtable's OAuth scopes documentation for details on available scopes.
    • Common scopes include:
      • data.records:read - Read records from bases
      • data.records:write - Create, edit, and delete records
      • schema.bases:read - Read base schema information
      • schema.bases:write - Create and modify base schema
      • webhook:manage - Create and manage webhooks
  5. Click Save to create the integration.
  6. Copy the Client ID and Client secret values displayed on the integration details page.

Configure the Connection​

  • Enter the Client ID and Client Secret from the OAuth integration.
  • For Scopes, enter the selected scopes as a space-separated list. For example: 
    data.records:read data.records:write schema.bases:read webhook:manage
  • The default scopes include common permissions for reading, writing, and managing webhooks. Adjust the scopes based on the specific requirements of the integration.

The connection is now ready to authenticate with Airtable.

InputNotesExample
Authorize URL

The OAuth 2.0 Authorization URL for Airtable

https://airtable.com/oauth2/v1/authorize
Client ID

Provide the Client ID you received from https://airtable.com/create/oauth.

cli1234567890abcd
Client Secret

Provide the Client Secret you received from https://airtable.com/create/oauth.

Scopes

A space-delimited set of one or more scopes to get the user's permission to access.

data.records:read data.records:write data.recordComments:read data.recordComments:write schema.bases:read schema.bases:write webhook:manage
Token URL

The OAuth 2.0 Token URL for Airtable

https://airtable.com/oauth2/v1/token

Personal Access Token​

key: personalAccessToken

A personal access token provides user-specific access to Airtable bases and can be used for testing integrations or for user-scoped operations.

Personal Access Tokens vs OAuth 2.0

Personal access tokens are user-scoped and suitable for testing or personal automations. For production integrations where users need to authenticate with their own credentials, OAuth 2.0 is recommended.

Prerequisites​

  • An Airtable account with access to the bases that will be accessed

Setup Steps​

To generate a personal access token:

  1. Log in to Airtable and navigate to airtable.com/create/tokens.
  2. Click Create new token.
  3. Enter a descriptive Token name to identify the token's purpose.
  4. Under Scopes, select the permissions required for the integration. Refer to Airtable's scopes documentation for details on available scopes.
    • Common scopes include:
      • data.records:read - Read records from bases
      • data.records:write - Create, edit, and delete records
      • schema.bases:read - Read base schema information
      • schema.bases:write - Create and modify base schema
  5. Under Access, select the specific bases the token should have access to, or select All current and future bases in all current and future workspaces for broader access.
  6. Click Create token.
  7. Copy the token value immediately. The token will not be shown again after leaving the page.

The token format will look similar to: patAbCdEfGh1234567.1234567890abcdefghijklmnopqr

Configure the Connection​

  • Enter the personal access token into the API Key field of the connection configuration.
Token Security

Store the token securely. Personal access tokens do not expire but can be revoked at any time from the token management page.

InputNotesExample
API Key

You can generate an API key from https://airtable.com/create/tokens

patAbCdEfGh1234567.1234567890abcdefghijklmnopqr

Triggers​

Base Change Notifications​

Receive base change notifications from Airtable. Automatically creates and manages a webhook subscription when the instance is deployed, and removes the subscription when the instance is deleted. | key: baseChanges

InputNotesExample
Connection

The Airtable connection to use.

Base ID

The ID of the base to interact with.

appLkNDICXNqxSDhG
Data Types

Types of changes to monitor.

tableData
Record Change Scope

Optional table ID or view ID to limit webhook to specific table/view. Leave empty to monitor all tables in base.

tblMwMnUJpKoJUDzo

The Base Change Notifications trigger automatically creates and manages an Airtable webhook subscription that monitors changes to a base. When the instance is deployed, the trigger creates the webhook; when the instance is deleted, the webhook is automatically removed. The trigger uses cursor-based payload retrieval and includes automatic webhook refresh functionality to prevent expiration.

For more information about Airtable's webhook system, see the Airtable Webhooks API documentation.

Lifecycle Behavior​

Instance Deploy​

When an instance with this trigger is deployed, the trigger:

  1. Checks for existing webhook: If a webhook was previously created and exists in the instance state, the trigger validates whether it still exists in Airtable
  2. Handles configuration changes: If the configuration (base ID, data types, or record change scope) has changed, the trigger deletes the old webhook before creating a new one
  3. Creates webhook: Calls the Airtable API to create a new webhook subscription with the specified configuration
  4. Stores state: Saves the webhook ID, MAC secret, expiration time, cursor, and configuration details in cross-flow state

Instance Update​

When an instance is redeployed with configuration changes:

  • If the base ID, data types, or record change scope has changed, the trigger deletes the old webhook and creates a new one with the updated configuration
  • If the configuration remains the same, the existing webhook is retained

Instance Delete​

When an instance is deleted or disabled:

  • The trigger automatically deletes the webhook from Airtable using the webhook ID stored in state
  • The cross-flow state is cleared
  • If the webhook was already deleted in Airtable (404 response), the deletion is handled gracefully

Webhook Events​

This trigger uses two branches to handle different types of events:

Notification Branch​

The Notification branch processes webhook notifications from Airtable when changes occur in the monitored base. When invoked:

  1. Validates signature: Uses the stored MAC secret to verify the webhook payload is authentic
  2. Retrieves payloads: Fetches all change payloads using cursor-based pagination from the Airtable Webhooks API
  3. Auto-refreshes webhook: Automatically extends the webhook expiration if needed
  4. Updates state: Stores the latest cursor and new expiration time
  5. Returns data: Provides the notification ping, all retrieved payloads, payload count, and cursor

Refresh Branch​

The Refresh branch handles scheduled invocations to prevent webhook expiration. Airtable webhooks expire after 7 days without a refresh. Configure a schedule (recommended: daily or every few days) to keep the webhook active. When invoked by schedule:

  1. Extends expiration: Calls the Airtable API to refresh the webhook
  2. Updates state: Stores the new expiration time
  3. Returns confirmation: Provides the new expiration time and success message

Configuration​

The trigger requires the following inputs:

  • Connection: An Airtable OAuth or API key connection
  • Base ID: The ID of the Airtable base to monitor (e.g., appLkNDICXNqxSDhG)
  • Data Types: Types of changes to monitor (default: tableData for record changes)
    • tableData - Monitor record changes (create, update, delete)
    • tableFields - Monitor schema changes (field additions, modifications)
    • tableMetadata - Monitor table metadata changes
  • Record Change Scope (optional): A specific table ID or view ID to limit monitoring (e.g., tblMwMnUJpKoJUDzo). Leave empty to monitor all tables in the base

Schedule Configuration​

To prevent webhook expiration, configure a schedule for the trigger:

  1. In the integration designer, select the trigger
  2. Enable Schedule in the trigger configuration
  3. Set the schedule to run every 1-3 days (recommended: daily)
  4. When the schedule runs, the Refresh branch will execute and extend the webhook expiration

Returned Data​

Notification Branch​

When a change notification is received, the trigger returns:

Notification branch response payload
{
  "notification": {
    "base": {
      "id": "appLkNDICXNqxSDhG"
    },
    "webhook": {
      "id": "ach00000000000001"
    },
    "timestamp": "2023-09-15T18:30:00.000Z"
  },
  "payloads": [
    {
      "timestamp": "2023-09-15T18:30:00.000Z",
      "actionMetadata": {
        "source": "publicApi",
        "sourceMetadata": {}
      },
      "changedTablesById": {
        "tblMwMnUJpKoJUDzo": {
          "createdRecordsById": {
            "rec123abc": {
              "createdTime": "2023-09-15T18:30:00.000Z",
              "cellValuesByFieldId": {
                "fldXYZ789": "New Value"
              }
            }
          },
          "changedRecordsById": {
            "rec456def": {
              "current": {
                "cellValuesByFieldId": {
                  "fldABC123": "Updated Value"
                }
              },
              "previous": {
                "cellValuesByFieldId": {
                  "fldABC123": "Old Value"
                }
              },
              "unchanged": {
                "cellValuesByFieldId": {
                  "fldDEF456": "Unchanged"
                }
              }
            }
          },
          "destroyedRecordIds": ["rec789ghi"]
        }
      }
    }
  ],
  "payloadCount": 1,
  "cursor": 5
}

Refresh Branch​

When the webhook is refreshed by schedule, the trigger returns:

Refresh branch response payload
{
  "expirationTime": "2023-09-22T18:30:00.000Z",
  "message": "Webhook refreshed"
}

Branch Logic​

Use branch routing in the integration flow to handle different event types:

  • Route the Notification branch to process base changes (record updates, schema changes, etc.)
  • Route the Refresh branch to log successful refresh events or send notifications
Example flow structure
[Base Change Notifications Trigger]
  |
  ├─ Notification → [Process Changes] → [Update Records]
  |
  └─ Refresh → [Log Refresh] → [Send Status Email]

Important Notes​

  • Webhook Expiration: Airtable webhooks expire after 7 days without activity. The trigger includes automatic refresh functionality, but a schedule must be configured for this to work
  • MAC Signature Verification: All webhook payloads are validated using HMAC-SHA256 signature verification to ensure authenticity
  • Cursor Management: The trigger uses cursors to track processed payloads and avoid duplicate processing
  • State Management: Webhook metadata is stored in cross-flow state and persists across executions
  • Configuration Changes: Changing the base ID, data types, or record change scope will delete and recreate the webhook

Comparison with Manual Webhook Trigger​

The Airtable component includes two webhook triggers:

  • Base Change Notifications (this trigger): Automatically creates and manages webhook subscriptions with lifecycle handlers, cursor-based retrieval, and auto-refresh
  • Webhook: A simple webhook receiver for manually configured Airtable webhooks (configured outside the integration)

Use the Base Change Notifications trigger for automated webhook management with built-in expiration prevention. Use the Webhook trigger if webhooks are managed externally or if simple webhook reception is needed without lifecycle management.

Example Payload for Base Change Notifications⤓
Loading…

New and Updated Records​

Checks an Airtable table for new and updated records on a configured schedule, using LAST_MODIFIED_TIME() as the server-side filter. Records are partitioned by createdTime versus lastPolledAt: records whose createdTime is after lastPolledAt go to the created bucket, while older records modified since lastPolledAt go to the updated bucket. | key: pollChangesTrigger

InputNotesExample
Additional Filter Formula

Optional Airtable formula combined (AND) with the modification-time filter applied by the trigger.

{Status} = 'Active'
Connection

The Airtable connection to use.

Base ID

The ID of the base containing the table to poll.

appLkNDICXNqxSDhG
View

Optional view (name or ID) to scope the poll to. When set, only records in that view are considered.

Grid view
Show New Records

When true, records with a createdTime after the last poll are included in the trigger results.

true
Show Updated Records

When true, records modified after the last poll (but created earlier) are included in the trigger results.

true
Table Name

The name of the table to access.

Marketing Campaigns

The New and Updated Records trigger checks an Airtable table for new and updated records on a configured schedule. It uses Airtable's built-in LAST_MODIFIED_TIME() formula function as the server-side filter, then partitions the returned records into created and updated buckets based on each record's createdTime versus the trigger's lastPolledAt cursor.

For information on Airtable's formula functions and the record fields used by this trigger, see the Airtable Web API documentation.

How It Works​

  1. The trigger runs on the configured schedule (for example, every five minutes).
  2. It queries the configured table with a filterByFormula of IS_AFTER(LAST_MODIFIED_TIME(), DATETIME_PARSE("<lastPolledAt>")). When an Additional Filter Formula is supplied, it is combined with the modification-time filter using AND(...).
  3. The Airtable response is paginated via the offset cursor; the trigger follows up to 100 pages of 100 records (10,000 records per poll).
  4. Records are partitioned into two buckets:
    • created: records whose createdTime is strictly after lastPolledAt.
    • updated: records that existed before lastPolledAt but were modified since.
  5. The trigger advances lastPolledAt and returns the partitioned records.
Cursor Advancement and Truncation Semantics​

Airtable's offset pagination does not guarantee a stable record ordering across pages. To preserve at-least-once delivery semantics:

  • Non-truncated polls: the cursor advances to the poll start time (now). All records modified after the previous lastPolledAt were fetched in this run.
  • Truncated polls (the page cap was hit and an offset was still present): the cursor advances to the latest createdTime observed in the fetched page set, never beyond it. Because LAST_MODIFIED_TIME() >= createdTime for every record, this never overshoots the true modification cursor. Older un-fetched records will be re-detected on the next poll, and a warning is logged with the new cursor value.
Partitioning Rule​

For each record in the response, given lastPolledAtDate = new Date(lastPolledAt):

  • If record.createdTime is a valid string and new Date(record.createdTime) > lastPolledAtDate and Show New Records is enabled, the record is appended to created.
  • Otherwise, if Show Updated Records is enabled, the record is appended to updated.

A record cannot appear in both buckets within a single poll.

State Management​

The trigger persists a single state value, lastPolledAt, via context.polling.setState(). On the first poll, lastPolledAt defaults to the current time, so only records created or modified after deployment are returned.

When the partitioned result is empty, the trigger returns polledNoChanges: true, which the platform uses to suppress empty invocations.

Configuration​

Configure the following inputs:

  • Airtable Connection: An OAuth 2.0 or personal access token connection used to authenticate Airtable API requests.
  • Base ID: The ID of the base containing the table to poll (for example, appLkNDICXNqxSDhG).
  • Table Name: The name or ID of the Airtable table to poll.
  • View (optional): A view name or ID. When set, only records in that view are considered for the poll.
  • Additional Filter Formula (optional): An Airtable formula combined (via AND) with the modification-time filter. For example, {Status} = 'Active'.
  • Show New Records (default: true): When enabled, records whose createdTime is after lastPolledAt are included in the created bucket.
  • Show Updated Records (default: true): When enabled, records modified after lastPolledAt (but created earlier) are included in the updated bucket.

Returned Data​

The trigger returns an object with created and updated arrays under body.data. Each record contains its Airtable id, the original createdTime, and the requested fields.

Example Payload
{
  "payload": {
    "body": {
      "data": {
        "created": [
          {
            "id": "recABCDEFGHIJ1234",
            "createdTime": "2026-05-25T14:30:00.000Z",
            "fields": {
              "Name": "Acme Spring Launch",
              "Status": "Active",
              "Notes": "Newly created campaign record."
            }
          }
        ],
        "updated": [
          {
            "id": "recXYZWVUTSR5678",
            "createdTime": "2026-04-10T09:15:00.000Z",
            "fields": {
              "Name": "Q1 Holiday Campaign",
              "Status": "Completed",
              "Notes": "Existing record, modified after last poll."
            }
          }
        ]
      }
    }
  },
  "polledNoChanges": false
}

Notes​

  • Page cap: The trigger fetches a maximum of 10,000 records per poll (100 pages of 100 records). If this cap is hit, the cursor advances to the latest observed createdTime and a warning is logged. Older un-fetched records are re-detected on the next poll. For tables with very high write volume, prefer a shorter polling interval over a single large catch-up.
  • Polling cadence: Avoid polling intervals shorter than one minute to stay within Airtable's API rate limits (5 requests per second per base).
  • First poll: On the first poll, the cursor defaults to the deployment time. Pre-existing records are not returned.
  • Field changes only: Airtable's LAST_MODIFIED_TIME() reflects field modifications. Schema changes, comment additions, and other metadata changes are not detected by this trigger. Use the Base Change Notifications trigger for schema and metadata events.
  • View scoping: Setting View restricts the polled records to those visible in that view. Filters defined on the view are applied server-side by Airtable in addition to the trigger's modification-time filter.

Comparison with Webhook Triggers​

The Airtable component includes three triggers for detecting changes:

  • New and Updated Records (this trigger): Schedule-driven polling with created versus updated partitioning. No webhook lifecycle to manage.
  • Base Change Notifications: Automatic webhook subscription with lifecycle handlers, cursor-based payload retrieval, and auto-refresh. Detects record, schema, and metadata changes.
  • Webhook: Receives manually configured Airtable webhooks without lifecycle management.

Use New and Updated Records when polling is acceptable and a simple created versus updated split is sufficient. Use Base Change Notifications for near-real-time delivery with full change payloads (including deleted records and schema changes).

Example Payload for New and Updated Records⤓
Loading…

Webhook​

Receive and validate webhook requests from Airtable for manually configured webhook subscriptions. | key: webhook

The Webhook trigger receives webhook requests from manually configured Airtable webhooks. This trigger is designed for scenarios where webhooks are created and managed outside the integration using Airtable's API or automation interface.

For information about creating Airtable webhooks manually, see the Airtable Webhooks API documentation.

When to Use This Trigger​

Use this trigger when:

  • Webhooks are created and managed using Airtable's API or Automations interface directly
  • Multiple integrations need to receive the same webhook events
  • Webhook lifecycle needs to be controlled independently from instance deployment
  • Simple webhook reception is needed without automatic lifecycle management

For automatic webhook creation and management with built-in expiration prevention and cursor-based retrieval, use the Base Change Notifications trigger instead.

Configuration​

This trigger requires no configuration inputs. It simply receives and returns webhook payloads as-is.

Setting Up the Webhook URL​

  1. Deploy the instance containing this trigger
  2. Copy the webhook URL from the trigger's configuration in the instance
  3. Create an Airtable webhook manually using one of these methods:
  4. Configure the webhook specification to define which events to monitor

Webhook Payload Structure​

The trigger receives the raw webhook payload from Airtable and returns it unchanged. A typical Airtable webhook notification includes:

Webhook notification payload
{
  "base": {
    "id": "appLkNDICXNqxSDhG"
  },
  "webhook": {
    "id": "ach00000000000001"
  },
  "timestamp": "2023-09-15T18:30:00.000Z"
}

After receiving the notification ping, use the List webhook payloads endpoint to retrieve the actual change data using the webhook ID and cursor values.

Example Webhook Payloads​

Record Created Event
{
  "base": {
    "id": "appLkNDICXNqxSDhG"
  },
  "webhook": {
    "id": "ach00000000000001"
  },
  "timestamp": "2023-09-15T18:30:00.000Z"
}
Table Schema Changed Event
{
  "base": {
    "id": "appLkNDICXNqxSDhG"
  },
  "webhook": {
    "id": "ach00000000000001"
  },
  "timestamp": "2023-09-15T19:45:00.000Z"
}
Multiple Changes Event
{
  "base": {
    "id": "appLkNDICXNqxSDhG"
  },
  "webhook": {
    "id": "ach00000000000002"
  },
  "timestamp": "2023-09-15T20:15:00.000Z"
}

Returned Data​

The trigger returns the complete webhook payload structure:

Complete webhook payload structure
{
  "headers": {
    "Accept": "*/*",
    "Content-Type": "application/json",
    "Host": "hooks.example.com",
    "User-Agent": "Airtable (https://airtable.com)"
  },
  "queryParameters": {},
  "rawBody": {
    "data": "<data (547 bytes)>"
  },
  "body": {
    "data": [
      {
        "id": "recExample123",
        "fields": {
          "Field 1": "Example Value 1",
          "Field 2": "Example Value 2"
        },
        "createdTime": "2023-01-01T00:00:00.000Z"
      }
    ],
    "contentType": "application/json"
  },
  "pathFragment": "",
  "webhookUrls": {
    "Flow 1": "https://hooks.example.com/trigger/EXAMPLE_ID"
  },
  "webhookApiKeys": {
    "Flow 1": ["example-api-key"]
  },
  "invokeUrl": "https://hooks.example.com/trigger/EXAMPLE_ID",
  "executionId": "ExecutionResult:example-execution-id",
  "customer": {
    "id": "customerId",
    "name": "Customer Name",
    "externalId": "externalId"
  },
  "instance": {
    "id": "instanceId",
    "name": "Instance Name"
  },
  "user": {
    "id": "userId",
    "email": "user@example.com",
    "name": "User Name",
    "externalId": "userExternalId"
  },
  "integration": {
    "name": "Integration Name",
    "id": "integrationId",
    "versionSequenceId": "1",
    "externalVersion": "1"
  },
  "flow": {
    "name": "Flow Name",
    "id": "flowId"
  },
  "startedAt": "2023-01-01T00:00:00.000Z",
  "globalDebug": false
}

Processing Webhook Data​

After receiving the notification ping, the integration flow should:

  1. Extract webhook metadata: Get the webhook.id and base.id from the payload
  2. Retrieve change details: Call the List webhook payloads endpoint to get actual change data
  3. Process changes: Parse the change payloads and take appropriate actions
  4. Track cursor: Store the cursor value to avoid reprocessing payloads
Example flow
[Webhook Trigger]
  → [Extract Webhook ID]
  → [List Webhook Payloads Action]
  → [Process Changes Loop]
  → [Update Records]

Important Notes​

  • No Automatic Lifecycle Management: This trigger does not create, refresh, or delete webhooks. Webhook management must be handled separately
  • No Signature Verification: This trigger does not verify webhook signatures. Implement verification in the flow if needed using the MAC secret from webhook creation
  • No Cursor Management: The trigger does not track cursors or retrieve payloads automatically. The flow must implement cursor tracking
  • Webhook Expiration: Airtable webhooks expire after 7 days without a refresh. Implement refresh logic separately using the Refresh webhook endpoint
  • Raw Payload: The trigger returns the webhook notification as-is without transformation

Comparison with Base Change Notifications Trigger​

The Airtable component includes two webhook triggers:

  • Webhook (this trigger): Receives manually configured Airtable webhooks without lifecycle management
  • Base Change Notifications: Automatically creates and manages webhook subscriptions with lifecycle handlers, cursor-based retrieval, and auto-refresh

Use this Webhook trigger for simple webhook reception when webhooks are managed externally. Use the Base Change Notifications trigger for automated webhook management with built-in expiration prevention and payload retrieval.

Additional Resources​

Data Sources​

Select Base​

Select an Airtable base from a dropdown. | key: selectBase | type: picklist

InputNotesExample
Connection

The Airtable connection to use.

Include ID in Dropdown

When true, the base or table ID is shown next to each dropdown menu option.

false

Select Record​

Select a record from a table. | key: selectRecord | type: picklist

InputNotesExample
Connection

The Airtable connection to use.

Base ID

The ID of the base to interact with. Required if you use an OAuth connection, and optional if you specify base ID with a legacy API Key connection.

appLkNDICXNqxSDhG
Include ID in Dropdown

When true, the base or table ID is shown next to each dropdown menu option.

false
Table Name

The name of the table to access.

Marketing Campaigns

Select Table​

Select a table from an Airtable base. | key: selectTable | type: picklist

InputNotesExample
Connection

The Airtable connection to use.

Base ID

The ID of the base to interact with. Required if you use an OAuth connection, and optional if you specify base ID with a legacy API Key connection.

appLkNDICXNqxSDhG
Include ID in Dropdown

When true, the base or table ID is shown next to each dropdown menu option.

false

Select Webhook​

Select a webhook subscription from an Airtable base. | key: selectWebhook | type: picklist

InputNotesExample
Connection

The Airtable connection to use.

Base ID

The ID of the base to interact with. Required if you use an OAuth connection, and optional if you specify base ID with a legacy API Key connection.

appLkNDICXNqxSDhG
Include ID in Dropdown

When true, the base or table ID is shown next to each dropdown menu option.

false

Actions​

Create Record​

Create a new record in the specified table. | key: createRecord

InputNotesExample
Connection

The Airtable connection to use.

Base ID

The ID of the base to interact with. Required if you use an OAuth connection, and optional if you specify base ID with a legacy API Key connection.

appLkNDICXNqxSDhG
Dynamic Fields

A JSON array of key-value pairs that can be configured at deploy time with a key-value config variable. When provided, the default 'Record Fields' input is ignored.

[
  {
    "key": "name",
    "value": "My Example Account"
  },
  {
    "key": "phone",
    "value": "5551234567"
  }
]
Record Fields

The key-value pairs to set on the record. Each key maps to a column name in the table.

Table Name

The name of the table to access.

Marketing Campaigns
Example Payload for Create Record⤓
Loading…

Create Webhook​

Create a new webhook subscription for a base. | key: createWebhook

InputNotesExample
Connection

The Airtable connection to use.

Base ID

The ID of the base to interact with. Required if you use an OAuth connection, and optional if you specify base ID with a legacy API Key connection.

appLkNDICXNqxSDhG
Notification URL

The URL that receives notification pings when the webhook fires.

https://your-webhook-endpoint.com/airtable/notifications
Specification

A JSON object describing the types of changes the webhook listens for.

{
  "options": {
    "filters": {
      "fromSources": [
        "publicApi"
      ],
      "dataTypes": [
        "tableData"
      ],
      "recordChangeScope": "tblMwMnUJpKoJUDzo"
    }
  }
}
Example Payload for Create Webhook⤓
Loading…

Delete Record​

Delete a record from the specified table. | key: deleteRecord

InputNotesExample
Connection

The Airtable connection to use.

Base ID

The ID of the base to interact with. Required if you use an OAuth connection, and optional if you specify base ID with a legacy API Key connection.

appLkNDICXNqxSDhG
Record ID

The unique identifier for the record. Functions as the primary key for the row in the table.

rec6r4kNmGDk5D52F
Table Name

The name of the table to access.

Marketing Campaigns
Example Payload for Delete Record⤓
Loading…

Delete Webhook​

Delete a webhook subscription from a base. | key: deleteWebhook

InputNotesExample
Connection

The Airtable connection to use.

Base ID

The ID of the base to interact with. Required if you use an OAuth connection, and optional if you specify base ID with a legacy API Key connection.

appLkNDICXNqxSDhG
Webhook ID

The unique identifier for the webhook.

ach00000000000001
Example Payload for Delete Webhook⤓
Loading…

Get Base Schema​

Retrieve the schema of all tables within a base. | key: getBaseSchema

InputNotesExample
Connection

The Airtable connection to use.

Base ID

The ID of the base to interact with. Required if you use an OAuth connection, and optional if you specify base ID with a legacy API Key connection.

appLkNDICXNqxSDhG
Example Payload for Get Base Schema⤓
Loading…

Get Current User​

Retrieve the user ID and OAuth scopes for the current user. | key: getCurrentUser

InputNotesExample
Connection

The Airtable connection to use.

Example Payload for Get Current User⤓
Loading…

Get Record​

Retrieve a record by ID from the specified table. | key: getRecord

InputNotesExample
Connection

The Airtable connection to use.

Base ID

The ID of the base to interact with. Required if you use an OAuth connection, and optional if you specify base ID with a legacy API Key connection.

appLkNDICXNqxSDhG
Record ID

The unique identifier for the record. Functions as the primary key for the row in the table.

rec6r4kNmGDk5D52F
Table Name

The name of the table to access.

Marketing Campaigns
Example Payload for Get Record⤓
Loading…

List Bases​

List all bases within the Airtable account. | key: listBases

InputNotesExample
Connection

The Airtable connection to use.

Example Payload for List Bases⤓
Loading…

List Records​

List all records within the specified table. | key: listRecords

InputNotesExample
Connection

The Airtable connection to use.

Base ID

The ID of the base to interact with. Required if you use an OAuth connection, and optional if you specify base ID with a legacy API Key connection.

appLkNDICXNqxSDhG
Fields

The names (or IDs) of the fields to return. When omitted, all fields are returned.

Name, Email, Status
Filter By Formula

An Airtable formula used to limit results to records matching specific criteria.

AND({Quantity} * {Price} > 100, NOT({Shipped?}))
Table Name

The name of the table to access.

Marketing Campaigns
View

The name or ID of a view in the table. When set, only records in that view are returned, sorted in the order defined by the view.

Grid view

Filtering Records​

Filter for specific records using the Filter By Formula input. For example, to return only records where the product of the Quantity and Price fields is greater than 100 and the record's Shipped? field is not checked, use a formula like this:

AND({Quantity} * {Price} > 100, NOT({Shipped?}))

Full documentation on Airtable formulas is available on the Airtable support site.

Example Payload for List Records⤓
Loading…

List Webhooks​

List all webhook subscriptions registered for a base. | key: listWebhooks

InputNotesExample
Connection

The Airtable connection to use.

Base ID

The ID of the base to interact with. Required if you use an OAuth connection, and optional if you specify base ID with a legacy API Key connection.

appLkNDICXNqxSDhG
Example Payload for List Webhooks⤓
Loading…

Raw Request​

Send a raw HTTP request to Airtable. | key: rawRequest

InputNotesExample
Connection

The Airtable connection to use.

Data

The HTTP body payload to send to the URL.

{"exampleKey": "Example Data"}
File Data

File Data to be sent as a multipart form upload.

[{key: "example.txt", value: "My File Contents"}]
File Data File Names

File names to apply to the file data inputs. Keys must match the file data keys above.

Form Data

The Form Data to be sent as a multipart form upload.

[{"key": "Example Key", "value": new Buffer("Hello World")}]
Header

A list of headers to send with the request.

User-Agent: curl/7.64.1
Max Retry Count

The maximum number of retries to attempt. Specify 0 for no retries.

0
Method

The HTTP method to use.

Query Parameter

A list of query parameters to send with the request. This is the portion at the end of the URL similar to ?key1=value1&key2=value2.

Response Type

The type of data you expect in the response. You can request json, text, or binary data.

json
Retry On All Errors

If true, retries on all erroneous responses regardless of type. This is helpful when retrying after HTTP 429 or other 3xx or 4xx errors. Otherwise, only retries on HTTP 5xx and network errors.

false
Retry Delay (ms)

The delay in milliseconds between retries. This is used when 'Use Exponential Backoff' is disabled.

0
Timeout

The maximum time that a client will await a response to its request

2000
URL

The request path only (e.g., /v0/meta/bases/{BASE_ID}/tables). The base URL https://api.airtable.com is already included. For example, to call https://api.airtable.com/v0/meta/bases/{BASE_ID}/tables, enter only /v0/meta/bases/{BASE_ID}/tables in this field.

/v0/meta/bases/{BASE_ID}/tables
Use Exponential Backoff

Specifies whether to use a pre-defined exponential backoff strategy for retries. When enabled, 'Retry Delay (ms)' is ignored.

false
Example Payload for Raw Request⤓
Loading…

Refresh Webhook​

Extend the expiration of an existing webhook subscription. | key: refreshWebhook

InputNotesExample
Connection

The Airtable connection to use.

Base ID

The ID of the base to interact with. Required if you use an OAuth connection, and optional if you specify base ID with a legacy API Key connection.

appLkNDICXNqxSDhG
Webhook ID

The unique identifier for the webhook.

ach00000000000001
Example Payload for Refresh Webhook⤓
Loading…

Update Record​

Update the field values of a record in the specified table. | key: updateRecord

InputNotesExample
Connection

The Airtable connection to use.

Base ID

The ID of the base to interact with. Required if you use an OAuth connection, and optional if you specify base ID with a legacy API Key connection.

appLkNDICXNqxSDhG
Dynamic Fields

A JSON array of key-value pairs that can be configured at deploy time with a key-value config variable. When provided, the default 'Record Fields' input is ignored.

[
  {
    "key": "name",
    "value": "My Example Account"
  },
  {
    "key": "phone",
    "value": "5551234567"
  }
]
Record ID

The unique identifier for the record. Functions as the primary key for the row in the table.

rec6r4kNmGDk5D52F
Record Fields

The key-value pairs to set on the record. Each key maps to a column name in the table.

Table Name

The name of the table to access.

Marketing Campaigns
Example Payload for Update Record⤓
Loading…

Changelog​

2026-05-28​

Added New and Updated Records polling trigger that polls an Airtable table for records modified at or after the last poll, using the LAST_MODIFIED_TIME() formula function as the server-side filter. Records with createdTime after the last poll are emitted in the created bucket; older records modified since the last poll go to the updated bucket. Optional inputs allow scoping by view and combining additional Airtable formulas with the modification-time filter

2026-04-30​

Various modernizations and documentation updates

2025-12-17​

Added new triggers for receiving Airtable change notifications:

  • Added Base Change Notifications trigger with automatic webhook creation, cursor-based payload retrieval, and scheduled auto-refresh to prevent webhook expiration
  • Added Webhook trigger for receiving manually configured Airtable webhooks