Airtable integration

Last updated date:

How Seedling connects to Airtable, which read-only information it uses, and how access and deletion are controlled.

1. Overview

The Airtable integration reads explicitly authorized bases and projects their tables, views, records, comments, and schema into a Seedling workspace.

Airtable is schema-flexible: Seedling preserves the workspace's field and view vocabulary as evidence and does not assume that a table, status field, or view has a universal business meaning.

2. Connection and scope

Seedling verifies the provider account before storing the connection. A personal connection remains actor-owned; a workspace connection is administered for the selected Seedling workspace. Credentials are never inferred from an email address or silently promoted between scopes.

Personal access token or OAuth access token
The token must be granted access to each workspace or base Seedling should read. Token scopes and resource selection are separate controls.
Personal or workspace connection
A member may connect actor-owned access, or an administrator may connect an account for workspace use. Seedling verifies the Airtable user identity returned for the token.

3. Airtable data Seedling accesses

Seedling uses synchronized information for source-backed search, operating context, verification, and customer-approved workflows. Availability depends on the connected account, selected resources, provider plan, and native permissions.

Structure
Authorized workspaces, bases, tables, fields, field configuration, and views.
Records
Record identifiers, cell values, creation and modification context, and linked-record relationships returned by the authorized bases.
Comments and collaborators
Record comments and available user identity needed for attribution and native access projection when the recommended scopes are granted.

4. Read-only permission contract

The first two scopes are required. The remaining scopes enable comments, richer base metadata, user matching, and safer audience projection.

  • schema.bases:read — read base, table, field, and view schema.
  • data.records:read — read records in explicitly authorized bases.
  • data.recordComments:read — read record comments when available.
  • workspacesAndBases:read — read workspace and base metadata.
  • user.email:read — match available Airtable collaborators to active Seedling members.

5. Security and access

  • Provider credentials and other connection secrets are encrypted in the workspace tenant data plane, never returned to the browser, and excluded from logs and queue payloads.
  • Every source, synchronization, secret lookup, audience contribution, disconnect, and purge remains bound to the exact connection that created it.
  • Airtable is a projected-audience provider. Seedling uses provider-returned collaborator evidence when available; missing or unmappable access evidence contributes no human audience.
  • Personal-connection raw content remains visible only to the connecting member in human-facing Seedling surfaces.
  • Generated output cannot bypass Seedling's human review, verification, and approval gates.

6. Retention and deletion

Connected data
Synchronized Airtable records remain while the connection is active and are removed through a durable integration purge after disconnect.
Credentials
Stored Airtable credentials or connection secrets and connection-owned synchronization state are deleted from active Seedling systems as part of the purge.
Backups
Deleted information may remain in encrypted, access-restricted backups until expiry, ordinarily within 35 days after active-system deletion.