Skip to main content
airtable icon

Airtable Connector

Sourcenpm · v0.2.0API DocsAPI ChangelogConnector 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​

Retrieves existing and ongoing records in a specified Airtable table. Load history once, check for changes on a schedule, or both. | 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
Look-back Date

The date the initial sync starts from, in YYYY-MM-DD format. Cannot be a future date. Leave empty to start from the first recurrence with no backfill. When set, the initial sync seeds each record modified on or after this date once, ignoring the visibility filters.

2026-01-01
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. Records are partitioned into two buckets:
    • created: records whose createdTime is strictly after lastPolledAt.
    • updated: records that existed before lastPolledAt but were modified since.
  4. Outside an initial sync, Show New Records and Show Updated Records each gate one of the two result arrays. Turning either off empties that array, and both keys remain present in the payload.
  5. The trigger advances lastPolledAt and returns the partitioned records. When the result is empty and the stream is exhausted, the trigger returns polledNoChanges: true to suppress empty invocations.

Initial Sync

An initial sync seeds a complete starting state rather than a change feed, so inputs that narrow which changes are reported would leave gaps in it: Show New Records and Show Updated Records are ignored while it runs, and are the only inputs it ignores. It begins on the first recurrence, when the trigger has no stored position and a Look-back Date (YYYY-MM-DD) is set, and seeds every record modified on or after that date exactly once. Left empty, there is no sync and the trigger starts from its first recurrence.

The window has no fixed upper bound, so a record modified mid-drain is swept into the sync rather than deferred to the schedule. Once the stream is exhausted the position advances to the wall clock, and the first incremental recurrence resumes from exactly there; nothing in the payload marks the handoff. With batching off the trigger fetches up to 100 pages per recurrence; with batching on it fetches one page per round and the platform calls it again within the same recurrence until the stream is exhausted.

View, Additional Filter Formula, and the partitioning inputs still apply throughout. The trigger has no page-size or field-selection input, so nothing else is suppressed.

Batching

Batching is enabled per flow on this trigger: each changed record is dispatched as its own execution, or grouped by the configured batch size. Batch size and batch concurrency can both be overridden per instance. Raising concurrency increases the request volume sent to Airtable, which limits requests to 5 per second per base.

To turn it on, select the flow's trigger, open the Flow control tab, and switch on Enable Batching. Under Batch Size, keep Trigger default or choose Custom batch size. Batch Concurrency is optional; leave it blank for no batch-level limit.

With batching off a downstream step reads body.data.created and body.data.updated. With batching on those fields do not exist: each execution receives one { "changeType": ..., "record": ... } item, or an array of them when the batch size is greater than 1. Any step reading the older shape must be updated before batching is enabled, or it breaks the moment the switch is flipped. Because batching is enabled per flow, that change is scoped to the flow rather than to the component or to other flows using the same trigger.

Returned Data​

With batching off, the trigger returns an object with two arrays: created for new records and updated for modified records. Fields shown are representative. The full response object includes additional properties.

Example Response
{
  "data": {
    "created": [
      {
        "id": "recABCDEFGHIJ1234",
        "createdTime": "2026-05-25T14:30:00.000Z",
        "fields": {
          "Name": "Acme Spring Launch",
          "Status": "Active"
        }
      }
    ],
    "updated": [
      {
        "id": "recXYZWVUTSR5678",
        "createdTime": "2026-04-10T09:15:00.000Z",
        "fields": {
          "Name": "Q1 Holiday Campaign",
          "Status": "Completed"
        }
      }
    ]
  }
}

With batching on, each execution receives one record tagged with how it changed, or an array of such items when the batch size is greater than 1. The created and updated arrays are not part of this shape.

Batched Item
{
  "changeType": "created",
  "record": {
    "id": "recABCDEFGHIJ1234",
    "createdTime": "2026-05-25T14:30:00.000Z",
    "fields": {
      "Name": "Acme Spring Launch",
      "Status": "Active"
    }
  }
}

Notes​

  • Polling cadence: Avoid polling intervals shorter than one minute to stay within Airtable's API rate limits (5 requests per second per base).
  • 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.
  • The Airtable component also includes a Webhook trigger for receiving manually configured webhooks without lifecycle management.
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-11-05​

Updated spectral to 10.39.0

2026-11-03​

Published the component as an npm package, so code-native integrations can install it and call its actions, triggers and data sources from code with TypeScript types

2026-11-02​

Updated spectral to 10.34.1

2026-10-21​

  • Added opt-in batching to the New and Updated Records trigger, dispatching each changed record individually or in configured batches so large backlogs drain in one recurrence; enabling it changes the shape a downstream step receives
  • Added an optional Look-back Date input for performing an initial sync of records. The initial sync backfills every record modified on or after the specified date, beginning on the first recurrence, seeding each once, and ignoring the visibility filters. Leave it empty to start from the first recurrence with no backfill

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