Make.com Airtable Integration: How to Sync, Create, and Update Records Automatically

Airtable is one of the most flexible data management tools available for small teams and growing businesses. Make.com is one of the best platforms for automating what happens with that data. Combining them — syncing records between Airtable and other tools, triggering workflows from Airtable changes, or using Airtable as a structured data store for your automations — opens up a wide range of practical use cases.

This tutorial covers the Make.com Airtable integration from the ground up: connecting the two platforms, the key modules you will use, common integration patterns, and how to handle the parts that trip people up. If Make.com itself is new to you, start with Make.com Tutorial for Beginners.

Setting Up the Connection

Make.com has a native Airtable connector that uses the Airtable API. To connect them, you need an Airtable personal access token.

In Airtable, go to your account settings and navigate to the Developer Hub. Create a new personal access token, give it a descriptive name, and select the scopes you need. For most Make integrations, you need at minimum: data.records:read, data.records:write, and schema.bases:read. If you are creating or modifying tables, add schema.bases:write as well.

In Make.com, add an Airtable module to your scenario and create a new connection. Paste your personal access token. Make will validate it and list your available bases. Select the base you want to work with.

One connection per token. If you work across multiple Airtable bases or workspaces, you can use the same token as long as it has access to all of them, or create separate tokens with scoped access per base.

The Core Modules You Will Use

Make.com offers several Airtable modules. These four cover the vast majority of automation use cases.

Watch Records. This is a trigger module. It polls your Airtable base at a configurable interval — every 15 minutes down to every 1 minute depending on your Make plan — and returns any records that are new or modified since the last check. This is how you trigger a Make scenario when something changes in Airtable.

Search Records. Finds records matching a filter formula. Useful for looking up whether a record already exists before creating a duplicate, or for pulling a filtered subset of records to process.

Create a Record. Adds a new record to a specified table. You map field values from upstream modules to the Airtable field names. The module returns the created record including its Airtable Record ID.

Update a Record. Modifies an existing record. Requires the Record ID of the record to update, which you either get from a prior Search Records module or from data passed into the scenario by an earlier step.

Common Integration Pattern 1: Webhook to Airtable

One of the most common Make.com Airtable integrations is creating a new Airtable record whenever something happens in an external system — a form submission, a CRM event, a completed call, a payment.

The scenario structure: trigger on the event (Webhooks module or native connector), transform and validate the data as needed, then use Create a Record to write to Airtable.

For example, when a Retell AI call ends:

1. Webhooks module receives the post-call payload from Retell
2. A filter checks that call duration is above 30 seconds (ignore hang-ups)
3. A Set module extracts caller name, phone, and the reason for the call from the transcript
4. Airtable Create a Record writes these to a Leads table with the call date, duration, and a transcript URL

The Leads table in Airtable becomes a clean, structured log of every qualifying call, viewable and filterable without anyone manually entering data. Make.com Webhook Tutorial covers the receiving side of this pattern in full detail.

Common Integration Pattern 2: Airtable as a Workflow Trigger

The Watch Records module turns Airtable into a trigger surface. When a record is added or a specific field changes, Make responds.

A practical example: a client project management base in Airtable has a Status field. When a project record is moved to Status = Ready for Invoice, Make triggers and creates a draft invoice in QuickBooks or sends the invoice data to a billing system.

The setup: Watch Records on the Projects table, filter to only process records where Status changed to Ready for Invoice (use a formula filter or a Make filter on the output), then call the invoicing API.

Be aware that Watch Records polls rather than receiving a true webhook. If the timing of triggers matters — you need the automation to fire within seconds of the Airtable change — you need to supplement with Airtable Automations triggering a Make webhook instead. Airtable has a native automation builder that can send an HTTP request to a Make custom webhook URL the moment a record changes, which gives you near-real-time triggering.

Common Integration Pattern 3: Two-Way Sync Between Airtable and a CRM

Keeping Airtable and a CRM in sync is a common need for teams that use Airtable for project management and a CRM like GoHighLevel for sales and client communication. This is a similar pattern to the GHL-and-Airtable stacks covered in GoHighLevel Automation for Agencies, just with Airtable on the project-tracking side.

The pattern: when a deal is marked Won in the CRM, Make creates a corresponding project record in Airtable with the client name, service details, and start date. When the Airtable project status changes to Completed, Make updates the CRM contact record to reflect the project outcome and triggers a review request.

This requires two scenarios running in parallel: one triggered by the CRM event that writes to Airtable, and one triggered by the Airtable Watch Records that writes back to the CRM.

The key challenge in two-way syncs is avoiding infinite loops — an update from CRM to Airtable triggering an Airtable update that triggers the CRM sync again. Prevent this by using a dedicated field to track sync status, or by only watching for specific field changes rather than any record modification.

Working With Airtable Field Types

Airtable has a richer set of field types than a standard spreadsheet, and some of them require specific handling in Make.

Linked record fields. When a field links to records in another table, the value in Make is an array of Record IDs, not the display values. To get the display value, you need a separate Search Records call to look up the linked record by its ID. This is one of the more common surprises for people new to the Airtable API.

Attachment fields. Attachments in Airtable are stored as an array of objects, each with a URL, filename, and size. To write a file to an attachment field from Make, you need to pass a URL that Airtable can fetch from — not a raw file upload.

Formula and rollup fields. These are read-only in the API. You can read their computed values but you cannot set them directly. Do not try to write to them in your Create or Update modules.

Date fields. Airtable stores dates in ISO 8601 format. When writing dates from Make, format them correctly using the formatDate function: {{formatDate(now; "YYYY-MM-DD")}} for a date field, or include the time component for datetime fields.

The JSON Formatter is useful when you are working out the exact structure Airtable expects for complex field types like linked records and attachments.

Handling Large Record Sets

Airtable API returns a maximum of 100 records per request. If you are syncing or processing a large table, Make handles pagination automatically through the Search Records module — it fetches subsequent pages until all matching records are returned.

For very large tables (thousands of records), be mindful of Make.com operation counts. Each record returned from a Search Records call counts as one operation when iterated. Processing 500 records in a single scenario run consumes 500 operations. Plan your plan tier accordingly, or run batch processing scenarios on a schedule that distributes the load. The Make.com Pricing Calculator can help you check this against your plan before it becomes a problem.

Rate Limits

The Airtable API enforces a rate limit of 5 requests per second per base. Make.com does not automatically throttle to stay within this. For scenarios that make multiple Airtable calls in rapid succession — creating many records, running multiple lookups — add a Sleep module between Airtable calls if you are hitting rate limit errors (HTTP 429 responses).

For high-volume integrations, the Airtable API metadata tier (available on paid Airtable plans) provides higher rate limits.

Building Something Specific?

Make.com and Airtable together cover a wide range of practical data management and automation use cases. The integration patterns above handle the majority of what most teams need. The trickier scenarios — complex two-way syncs, linked record resolution, high-volume batch processing — are solvable with the right architecture, and it's the kind of Airtable-plus-CRM integration work I regularly build into larger automation stacks for clients.

If you want help building a specific Make.com Airtable integration or are hitting a wall with a particular field type or sync pattern, book a free 30-minute call. Bring your Airtable base structure and the outcome you are trying to achieve and we will work through the solution together.