Ellipse Gradient for Header

Airtable Integration Guide

Integrate Airtable bases, tables, records, attachments, and change notifications with enterprise systems through REST APIs, webhooks, and Martini workflows.

Airtable integration options at a glance

Airtable’s versioned Web API is the primary integration surface for reading and writing bases, tables, records, fields, views, and attachments. Airtable also provides a Webhooks API for selected base and record changes, multiple-record operations for applicable endpoints, and a CSV-oriented Sync API for supported scenarios. Personal access tokens support controlled server-to-server access, while OAuth 2.0 supports authorization across multiple users or organizations. Martini can consume these APIs, receive webhook notifications through an exposed endpoint, retrieve authoritative record state, map Airtable data to enterprise applications, batch writes, and orchestrate retries, reconciliation, and attachment transfers.

Integration pointSupported by Airtable?Common use casesHow Martini supports it
REST APIsYesAirtable’s versioned Web API supports listing, retrieving, creating, updating, deleting, and upserting Records, as well as reading schema metadata and managing webhook registrations.Martini can consume Airtable REST endpoints, expose reusable APIs, map responses and requests, paginate through results, and orchestrate writes to other systems.
Webhooks / outbound callbacksLimitedThe Airtable Webhooks API provides notifications for supported base and Record changes. Notifications are not a complete event stream for every Airtable action or object.Martini can expose a webhook endpoint, validate incoming notifications, retrieve the current Record, deduplicate events, and initiate downstream workflows.
Bulk / async / batch APIsLimitedAirtable supports multiple-record create, update, delete, and upsert operations within applicable request and record-count limits. Its CSV-oriented Sync API covers supported import scenarios.Martini can group records into batches, apply request-size controls, handle partial or transient failures, and retry with backoff.
File / attachment APIsYesAttachment fields can be read and files can be uploaded to Airtable attachment fields, enabling document transfer between Airtable and external repositories.Martini can retrieve attachment metadata and content, validate filenames and MIME types, upload files, and write destination identifiers or URLs back to Airtable.
AuthenticationYesAirtable supports personal access tokens for controlled access and OAuth 2.0 for applications serving multiple users or organizations. Legacy API keys are not recommended for new integrations.Martini can store PATs, OAuth client credentials, access tokens, and refresh tokens in secure configuration or secrets rather than workflow definitions.
Schema metadata APIsYesAirtable provides access to base and table schema metadata, which can help integrations detect field names, types, tables, and structural changes.Martini workflows can retrieve metadata during validation or deployment checks and apply explicit mappings and business rules to the returned structure.
CSV Sync APILimitedAirtable documents a CSV-oriented Sync API for importing tabular data in supported plans and scenarios. It is not a general replacement for record-level CRUD operations.Martini can generate or consume CSV data and invoke supported Airtable synchronization flows where the use case and Airtable plan permit it.
Database accessNoAirtable documents application-level APIs rather than SQL, JDBC, or direct database access.Martini should use Airtable’s REST API, Webhooks API, or documented file synchronization mechanisms instead of attempting direct database connectivity.

How Airtable exposes data and business events

Airtable REST APIs

Airtable’s versioned Web API is the primary integration mechanism for Bases, Tables, Records, Fields, Views, schema metadata, attachments, and webhook management. It supports record retrieval and mutation, filtering, sorting, pagination, and applicable multiple-record operations.

Martini implementation pattern

Martini implementation pattern: a workflow consumes the Airtable REST API using a PAT or OAuth 2.0 token stored in secure configuration. It retrieves pages or individual Records, maps Airtable values into a canonical model, applies business rules, and writes the result to target systems or back to Airtable.

Implementation sequence

Authenticate using a scoped PAT or OAuth 2.0 access token
Retrieve the Base, Table, View, or Record required by the workflow
Continue through paginated results until the required data is collected
Normalize Fields, linked-record values, dates, formulas, and attachments
Apply validation, ownership, and idempotency rules
Write the mapped result to the target system or Airtable in controlled batches

Airtable Webhooks

Airtable’s Webhooks API provides notifications for selected base and Record changes. Notifications may be incomplete, duplicated, delayed, out of order, or insufficient to determine the final business state without a follow-up read.

Martini implementation pattern

Martini implementation pattern: expose a controlled Martini API or webhook endpoint, validate the notification, identify the affected Airtable resource, and retrieve the current Record before applying downstream processing. Store event or Record correlation data to support deduplication and reconciliation.

Implementation sequence

Receive the Airtable webhook notification
Validate the request and any documented verification or signing mechanism
Identify the affected Base, Table, or Record
Retrieve the current Record when the notification does not contain complete state
Check duplicate, deletion, ordering, and replay conditions
Apply business rules and invoke downstream APIs or workflows

Airtable Batch Operations

Airtable supports multiple-record create, update, delete, and upsert patterns for applicable endpoints, subject to request-size and record-count limits. Airtable also documents a CSV-oriented Sync API for supported import scenarios.

Martini implementation pattern

Martini implementation pattern: collect eligible changes, transform them into Airtable’s batch request shape or supported CSV payload, partition the workload within Airtable limits, and retry transient failures without recreating successfully processed Records.

Implementation sequence

Collect records from the source application or reconciliation query
Map source objects to Airtable Table and Field structures
Partition the payload according to Airtable request and record limits
Submit the batch or supported CSV synchronization request
Record successful Airtable identifiers and failed items separately
Retry transient failures with backoff and route permanent validation errors for review

Airtable Attachment APIs

Airtable attachment Fields support metadata retrieval and file upload operations. Attachment URLs may not be suitable as permanent public storage locations, so integrations should copy content when durable retention is required.

Martini implementation pattern

Martini implementation pattern: retrieve attachment metadata and content, validate size, filename, MIME type, and access requirements, transfer the file to the destination, and optionally write the destination identifier or URL back to the Airtable Record.

Implementation sequence

Read the Airtable Record and attachment metadata
Retrieve the attachment while its URL is valid
Validate file type, size, filename, and destination requirements
Upload the file to the target repository or Airtable attachment Field
Persist the destination identifier or URL where appropriate
Handle unavailable, deleted, or expired attachment content

Common Airtable integration patterns

Pattern 1: Synchronize Airtable Records to a CRM

When to use this pattern

Use this pattern when Airtable supports operational planning while Salesforce or HubSpot remains authoritative for customer and account data. A webhook-triggered flow can reduce latency, while scheduled reconciliation can recover missed or unprocessable notifications.

Integration direction
Airtable
Martini
Salesforce
Example Mapping
Airtable FieldCanonical FieldTarget Field
record.idexternalRecordIdAirtable_Record_ID__c
NameaccountNameName
EmailprimaryEmailEmail
Last Modified TimesourceModifiedAtSource_Modified_At__c
Martini implementation pattern

Martini receives a supported Airtable webhook or starts a scheduled workflow, retrieves the authoritative Record, normalizes Fields and linked-record values, validates required CRM fields, and performs an idempotent Salesforce upsert. The workflow stores correlation identifiers, applies ownership rules, and routes validation failures separately from retryable API errors.

Martini capabilities used
  • workflows
  • API consumption
  • webhook receiving
  • data mapping
  • business rules
  • error handling

Pattern 2: Publish ERP Reference Data to Airtable

When to use this pattern

Use this pattern when NetSuite or another enterprise application owns products, customers, orders, or finance-related reference data and Airtable provides an operational planning or collaboration view.

Integration direction
NetSuite
Martini
Airtable
Example Mapping
Airtable FieldCanonical FieldTarget Field
internalIdsourceIdERP_ID
itemIdproductCodeProduct Code
displayNameproductNameProduct Name
quantityAvailableavailableQuantityAvailable Quantity
Martini implementation pattern

A scheduled Martini workflow retrieves changed source objects, paginates through the source response, applies field ownership and type conversions, and batches Airtable Record upserts using a stable external key. Rate limits, schema mismatches, and partial batch failures are captured for retry or review.

Martini capabilities used
  • scheduled workflows
  • API consumption
  • pagination
  • data mapping
  • batch orchestration
  • retry handling

Pattern 3: Route Airtable Change Events to ServiceNow

When to use this pattern

Use this pattern when Airtable is used to capture operational requests and ServiceNow owns case or task execution. It is appropriate for supported Record changes where the notification can initiate a follow-up read and workflow.

Integration direction
Airtable
Martini
ServiceNow
Example Mapping
Airtable FieldCanonical FieldTarget Field
Request TyperequestTypecategory
DescriptionrequestDescriptionshort_description
Priorityprioritypriority
record.idsourceRecordIdu_airtable_record_id
Martini implementation pattern

Martini validates the Airtable notification, retrieves the current Record, checks required fields and duplicate correlation keys, then creates or updates a ServiceNow task. The workflow writes the ServiceNow identifier and status back to Airtable where permitted and sends permanent validation failures to an operational queue or log.

Martini capabilities used
  • API exposure
  • workflow orchestration
  • data validation
  • business rules
  • API consumption
  • error handling

Pattern 4: Transfer Airtable Attachments to a Document Repository

When to use this pattern

Use this pattern when teams collect files in Airtable but long-term retention, access control, or document processing belongs in SharePoint, Google Drive, or an ERP document repository.

Integration direction
Airtable
Martini
SharePoint
Example Mapping
Airtable FieldCanonical FieldTarget Field
Attachments[].urlsourceFileUrlcontentSource
Attachments[].filenamefileNamename
Attachments[].typemimeTypecontentType
record.idsourceRecordIdexternalReference
Martini implementation pattern

A Martini workflow retrieves the current Record and attachment metadata, downloads each available file, validates content and destination constraints, uploads it to the repository, and records the resulting document identifier. It prevents duplicate transfers using the Airtable Record ID and attachment metadata and handles expired URLs as reviewable failures.

Martini capabilities used
  • workflows
  • API consumption
  • file handling
  • data mapping
  • idempotency
  • error handling

Applications commonly integrated with Airtable

Airtable is often used as an operational planning, collaboration, and lightweight application layer alongside enterprise applications. Martini can coordinate these exchanges while keeping ownership, mappings, validation, and retry behavior explicit.

Application Scenario Direction Martini Pattern
Salesforce Synchronize customer, account, campaign, or opportunity information with Airtable planning and operations tables. Salesforce → Martini → Airtable Use scheduled or API-triggered workflows to retrieve Salesforce objects, normalize fields and linked references, apply ownership rules, and upsert Airtable Records using a stored external identifier. Controlled Airtable changes can be returned to Salesforce where the data ownership model permits it.
HubSpot Move contacts, companies, campaigns, or marketing operations data into Airtable for coordination and reporting. HubSpot → Martini → Airtable Consume HubSpot API data in a Martini workflow, map selected properties to Airtable Fields, resolve select and linked-record values, and batch create or update Records while recording synchronization status.
Jira Connect Airtable project planning or product requirements with Jira issues and delivery status. Airtable → Martini → Jira Receive an Airtable webhook for supported changes, retrieve the current Record, validate project and issue fields, and create or update Jira issues. Store Jira issue identifiers in Airtable to support idempotent updates.
Slack Send Airtable change notifications, approvals, and exception alerts to channels or users. Airtable → Martini → Slack Expose a Martini webhook endpoint for Airtable notifications, retrieve the changed Record when required, render a concise message, and route business exceptions or approval requests to the appropriate Slack destination.
Google Sheets Exchange operational planning data, exports, or analyst-maintained lookup data with Airtable. Google Sheets → Martini → Airtable Schedule a Martini workflow to read or publish tabular data, normalize headers and data types, validate required values, and batch upsert Airtable Records using a stable key.
NetSuite Synchronize product, customer, order, or finance-related reference data used by operational teams in Airtable. NetSuite → Martini → Airtable Orchestrate NetSuite retrieval and Airtable writes in a workflow with explicit source ownership, field transformations, pagination, batch operations, and retry handling for rate limits or temporary failures.
ServiceNow Push Airtable requests or operational Records into ServiceNow cases or tasks and return status updates. Airtable → Martini → ServiceNow Use Airtable webhook notifications or scheduled polling to initiate a workflow, validate the request, create or update the ServiceNow task, and write the resulting identifier and status back to Airtable.
Shopify Coordinate product, inventory, catalog, or merchandising data maintained in Airtable with an online store. Shopify → Martini → Airtable Use scheduled workflows or upstream Shopify events to retrieve current data, map product and inventory fields, apply ownership and validation rules, and upsert Airtable Records or downstream Shopify resources without duplicate creation.

How to build a Airtable integration in Martini

Objective

Establish Airtable access using the authentication model appropriate to the integration scope and keep credentials outside workflow definitions.

Instructions in Martini

  • Choose a scoped personal access token for controlled server-to-server access or OAuth 2.0 for multi-user authorization
  • Store tokens, client secrets, and refresh-token configuration in Martini secure configuration or secrets
  • Use Airtable’s Bearer authorization format and request only required scopes
  • Record the authorized Base and workspace scope as environment-specific configuration

Objective

Select an event-driven, scheduled, or API-led starting point based on Airtable webhook coverage and synchronization requirements.

Instructions in Martini

  • Use a Martini API endpoint for supported Airtable webhook notifications
  • Use a scheduler for periodic listing, reconciliation, or CSV synchronization
  • Treat webhook notifications as change signals rather than complete business records
  • Define a recovery path for missed, delayed, duplicated, or out-of-order notifications

Objective

Read the authoritative Airtable state and handle pagination, views, formulas, linked records, and attachments deliberately.

Instructions in Martini

  • Retrieve the affected Record after a webhook when the notification is incomplete
  • Continue through Airtable offset-based pagination for list operations
  • Define whether the workflow reads all Records, a named View, or a formula-filtered result
  • Retrieve attachment content when it must be transferred or durably retained

Objective

Coordinate Airtable calls, target-system calls, transformations, validation, and status updates as a maintainable Martini workflow.

Instructions in Martini

  • Separate source retrieval, normalization, business decisions, target writes, and status recording
  • Use reusable integration logic for common authentication, pagination, and error handling
  • Track Airtable Record IDs and target identifiers for correlation
  • Use controlled batch sizes for multiple-record operations

Objective

Convert Airtable’s flexible Field structures into canonical and target-specific models without losing important identifiers or metadata.

Instructions in Martini

  • Normalize select objects, linked-record arrays, collaborator values, dates, formulas, and attachments
  • Map field names explicitly and validate expected data types
  • Preserve source Record IDs, Base IDs, filenames, MIME types, and external keys where relevant
  • Handle new select values, renamed Fields, deleted Fields, and schema drift as controlled changes

Objective

Apply ownership, validation, deduplication, and synchronization rules before writing to Airtable or downstream applications.

Instructions in Martini

  • Define which system owns each field and whether Airtable changes are authoritative
  • Validate required values and reject malformed data before target writes
  • Use stable external keys and Airtable Record IDs for idempotent upserts
  • Distinguish deleted, archived, unchanged, and materially updated Records

Common Airtable data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
BasesIdentify the Airtable workspace container and scope API operations to the appropriate business dataset.Martini configuration, Salesforce, NetSuite, ServiceNowMartini can store the base identifier as configuration, retrieve related schema metadata, and use it to scope record and webhook workflows.
TablesRepresent structured collections within a Base, such as customers, projects, requests, products, or operational tasks.Salesforce, Jira, ServiceNow, ShopifyMartini maps each Table to an explicit target object or process, validates table names and identifiers, and handles URL encoding where required.
RecordsRepresent individual rows identified by Airtable record IDs such as rec... and carry the operational data exchanged with other systems.Salesforce, HubSpot, Jira, ServiceNow, NetSuiteMartini retrieves, creates, updates, deletes, and upserts Records; it stores Airtable record IDs and external identifiers for correlation and idempotency.
FieldsContain text, number, date, select, linked-record, formula, collaborator, and attachment values within Tables.CRM, ERP, project management, collaboration, reporting applicationsMartini normalizes arrays, select objects, linked-record IDs, dates, formulas, and attachments before applying target-specific mappings and validation.
ViewsProvide saved table views that can influence record listing, filtering, and operational synchronization scope.Martini scheduled workflows, Google Sheets, Salesforce, reporting toolsMartini can request records through a named View or formula, but critical workflows should not rely on manually maintained view behavior without validation.
AttachmentsRepresent files stored in attachment Fields with metadata, filenames, MIME types, and download URLs.SharePoint, Google Drive, ERP document repositories, ServiceNowMartini can retrieve or copy attachment content, preserve metadata, upload files to another system or Airtable, and avoid treating attachment URLs as permanent storage.

Authentication and security considerations

Authentication options

Airtable supports personal access tokens for controlled server-to-server integrations and OAuth 2.0 for applications that authorize access on behalf of multiple users or organizations. Legacy API keys should not be used for new integrations.

  • Store PATs, OAuth client secrets, access tokens, refresh tokens, and webhook credentials in Martini secure configuration or secrets.
  • Request only the Airtable scopes and Base or workspace permissions required by each workflow.
  • Rotate credentials and refresh tokens according to the organization’s security policy.
  • Do not place credentials in workflow payloads, mappings, source files, or error messages.

Endpoint protection

Webhook endpoints exposed by Martini should validate Airtable requests and protect any verification or signing mechanism documented by Airtable. Apply authorization, network controls, and logging appropriate to the sensitivity of the Airtable data.

Operational considerations for Airtable integrations

Rate limits and pagination

Design workflows for Airtable rate limits, including base-level limits, and treat 429 responses as retryable. Avoid unnecessary polling, use webhooks where suitable, batch applicable operations, and continue through offset-based pagination until the required result set is complete.

Consistency and idempotency

Webhook notifications may be duplicated, delayed, or out of order and may not contain complete business state. Retrieve the current Record, use Airtable Record IDs and stable external keys for correlation, and combine event processing with scheduled reconciliation where missed changes matter.

Schema and data quality

Airtable users can rename Fields, change types, alter Views, add select values, or delete Tables and Fields. Use explicit version-controlled mappings, validate schema and required values, and normalize linked-record arrays, select objects, formulas, dates, and attachments.

Retries and testing

Retry temporary network and Airtable failures with exponential backoff, but do not retry permanent authorization, validation, or mapping errors indefinitely. Test duplicate notifications, deletion, pagination, rate limiting, partial batches, expired attachment URLs, and schema changes before production deployment.

Why use Martini instead of scripts or point-to-point integrations?

Coordinate more than API calls

Scripts can call Airtable endpoints, but enterprise integrations also require authentication management, pagination, field normalization, business ownership rules, target-system writes, retries, reconciliation, and operational visibility. Martini organizes these concerns into maintainable workflows and reusable integration assets.

Support multiple integration styles

Martini can consume Airtable REST APIs, receive supported webhook notifications, expose an API façade, process attachments, schedule reconciliation, and coordinate other enterprise APIs without coupling every system directly to Airtable.

Improve reliability and change control

  • Centralize secrets and environment-specific configuration.
  • Apply explicit mappings, validation, idempotency, and retry policies.
  • Separate transient API failures from permanent data-quality failures.
  • Monitor workflow execution and retain correlation information for troubleshooting.

Frequently asked questions

How can Airtable be integrated with enterprise systems?

Airtable can be integrated through its versioned REST Web API, Webhooks API for selected base and Record changes, multiple-record operations, attachment APIs, and supported CSV synchronization scenarios. Authentication can use personal access tokens or OAuth 2.0. Enterprise workflows commonly retrieve Airtable Records, map and validate Fields, write to systems such as Salesforce or ServiceNow, and use scheduled reconciliation alongside webhook processing.

Can Martini integrate with Airtable?

Yes. Martini can consume Airtable’s REST API, receive supported Airtable webhook notifications through an exposed API, process attachments, orchestrate batch operations, and synchronize Airtable data with enterprise applications. A dedicated native Martini Airtable connector is not documented in the supplied sources.

Do I need a connector to integrate Airtable with Martini?

No. A dedicated Airtable connector is not required. Martini can integrate using Airtable’s native REST API, Webhooks API, authentication methods, batch operations, attachment endpoints, and supported CSV synchronization mechanisms.

Is there any extra Lonti cost to integrate Airtable with Martini?

Lonti does not charge an additional per-connector or per-vendor fee to integrate Airtable with Martini. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Airtable, infrastructure, storage, or other third-party systems depending on subscription, API usage, and deployment model.

Which Airtable integration methods should an enterprise use?

Use Airtable’s REST Web API for current-state reads and writes, Webhooks API notifications for supported change events, and multiple-record operations when batching is appropriate. Use attachment APIs for file transfer and evaluate the CSV-oriented Sync API separately for supported import scenarios. Avoid legacy API keys for new implementations and do not assume direct SQL, JDBC, GraphQL, or SOAP access.

Can Airtable trigger a Martini workflow?

Yes, Airtable’s Webhooks API can notify an exposed Martini API about supported Base and Record changes. Webhooks are not a universal event stream, so the workflow should validate notifications, retrieve the current Record, handle duplicates and ordering issues, and use scheduled reconciliation when completeness is important.

How should Airtable synchronization handle mapping, retries, and duplicates?

Use explicit mappings for Airtable Fields, normalize arrays, linked-record values, select values, dates, formulas, and attachments, and define source ownership for each field. Store Airtable Record IDs and stable external keys for idempotent upserts. Retry rate-limit and temporary failures with backoff, while routing authentication, authorization, validation, and schema errors for review.

Can Martini expose an API façade for Airtable?

Yes. Martini can expose a controlled API that hides Airtable authentication, table identifiers, mapping rules, validation, and workflow orchestration from consuming applications. The façade can provide a stable enterprise contract while Martini translates requests to Airtable REST operations and applies security, logging, retry, and business rules.