Reference · built on requestConnectorFiles, documents & spreadsheets

Airtable

Bases, tables, records, and fields from Airtable through the Web API, with webhooks for record and schema changes.

Request accessPricing ↗

About

Airtable is a relational spreadsheet. A base holds tables of typed fields, views that filter and sort them, forms that write rows, and comments on records. Teams run trackers, content calendars, vendor lists, and count sheets in it. The Web API reads and writes records as JSON, and webhooks announce changes to data, fields, and table metadata.

Through Fibric, an operator reads the records that matter to a job, compares them with your other systems, and proposes a new record, an update, or a comment. You approve before anything is saved. The record is written once, and a receipt records what changed, why, and how to undo it.

This is a reference listing. It documents what Fibric would read from Airtable and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Records in a table or view through GET /v0/{baseId}/{tableIdOrName}, filtered with filterByFormula and sorted, 100 per page
  • Base schema (tables, fields, views) with the schema.bases:read scope
  • Record comments through the comments endpoints with data.recordComments:read
  • Webhook pings for tableData, tableFields, and tableMetadata changes, then the change payloads from list webhook payloads
  • Changes filtered by source: client, publicApi, formSubmission, automation, sync, and others
  • Cell changes in chosen fields through watchDataInFieldIds on the webhook specification

Proposed actions

  • Target capability: propose new records through POST /v0/{baseId}/{tableIdOrName}, with typecast for string values
  • Target capability: propose updates to existing records through PATCH /v0/{baseId}/{tableIdOrName}
  • Target capability: propose an upsert keyed on one to three fields through performUpsert and fieldsToMergeOn
  • Target capability: propose a comment on a record through POST /v0/{baseId}/{tableIdOrName}/{recordId}/comments, with a user mention

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Chase purchase orders tracked in a base

    The operator reads a purchase-order table each morning, finds lines past their expected date, proposes a comment on the record naming the supplier contact, and records what it asked.

    With PO Chase

  • Follow up on open actions

    A webhook ping fires when a status field changes. The operator fetches the payload, checks owners and due dates, and proposes a record update or a comment for your approval.

    With Action Follow-up

  • Reconcile a count sheet against the system

    Counts entered through an Airtable form arrive as formSubmission changes. The operator compares each count with the quantity your inventory system holds and proposes which variances to recount.

    With Count Variance

  • Know when a base stops updating

    The operator watches tableData payloads for the tables your reports depend on and proposes an alert when a table falls silent past its usual cadence.

    With Data Freshness

Requirements

  • An Airtable base and a token that has been granted access to that base
  • Scopes data.records:read and data.records:write, plus data.recordComments:read and data.recordComments:write for comments
  • schema.bases:read to read tables, fields, and views
  • webhook:manage and a public notification URL if you want change pings instead of polling
  • A service account managed from the enterprise admin panel, if the token should outlive one person's account
Authentication
A personal access token or OAuth access token sent as Authorization: Bearer, with scopes and explicit access to each base; the deprecation period for legacy API keys ended on February 1, 2024.

Limits

  • 5 requests per second per base, and 50 per second per token; after a 429, requests succeed again after 30 seconds
  • List calls return at most 100 records per page; longer tables are walked with offset
  • A webhook expires after 7 days unless refreshed, and a ping carries no data; payloads are fetched in a second request
  • Upserts match on at most three fields, and every matching record is updated

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Airtable ↗

Questions and answers

Do Airtable webhooks deliver the changed data?
No. Airtable sends a ping to your notification URL. Your application then calls list webhook payloads to fetch the changes. Pings are at-least-once and retried up to 13 times over about a day. Webhooks expire after 7 days unless refreshed.
What replaced API keys?
Personal access tokens and OAuth access tokens. The deprecation period for API keys ended on February 1, 2024. A token needs scopes for what it does and access to each base it touches; service accounts are managed from the enterprise admin panel.
How many records can one call return or write?
List records returns up to 100 per page, with offset for the next page and maxRecords as a ceiling. Create and update calls accept multiple records in one request; update supports performUpsert keyed on one to three fields.
Ask about Airtable

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with Airtable through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy