Airtable + Google Calendar: How I Keep Events in Sync With Make.com

Airtable date field is not as same as calendar event. They look like the same on screen, but the two systems handle all things in different ways. I spent months copying dates from Airtable into Google Calendar before I moved the work into Make. The workflow became useful when stopped treating it like a simple "create event" connection and started storing information needed to keep the same event alive.

The case that pushed me to fix it was a missed client deadline. The due date was sitting in our Airtable calendar. It never reached the shared Google Calendar, so the person responsible for the work planned the morning around something else. Since then I have treated the Calendar Event ID, timezone settings and archive flag as part of the data model.

Start by deciding which system owns the event

For this setup, Airtable is where the event is edited. The title, date, time and archive state live there. Google Calendar is the copy that people use during the day. I do not edit the synced Calendar event by hand because it will be overwritten the next time Airtable sends an update.

When somebody asks why an event moved from Tuesday to Wednesday, I only have one place to inspect: the Airtable record. If people start editing both systems, the workflow needs conflict rules and a second sync direction. I did not need that for the content calendar, so I left Calendar as the display layer.

Airtable's current API uses Personal Access Tokens instead of the old API keys. Airtable's API documentation was updated in June 2026, and the old API key approach has been deprecated for some time. citeturn306175search0turn306175search2

The Airtable fields for the sync

The table stays small. These are the fields for a normal event table:

• Event Title — Single line text
• Start Date — Date with time enabled
• End Date — Date with time enabled
• Calendar Event ID — Single line text
• Archived — Checkbox
• Last Modified Time — Airtable system field

The Calendar Event ID is the field that changed the whole build for me. Google Calendar gives every created event an ID. I put that value back into Airtable. On the next update, Make reads the ID and edits the same event.

Airtable's record-watch trigger can see new or changed records, but a deleted record has nothing left for a polling trigger to return. The checkbox gives Make a normal record update to work with before the Calendar event is removed.

More trouble than the API connection

The Airtable field must contain a time. A date like 2026-08-17 tells me the day, but it cannot tell Google Calendar if the event starts at 9 AM or 4 PM. I saw this during the first build when the Calendar module rejected a record that had a date but no time.

Open the Start Date field in Airtable and enable the time option. I do the same for End Date. For an all-day event, I handle it with a separate rule and send it as an all-day Calendar event instead of trying to force a time into the record.

There is another field setting I check before touching Make: the timezone. Airtable displays dates using the timezone configured for the base. Make then passes that value into the Calendar module. If the two sides are interpreted differently, the event can land several hours away from the time people entered.

Clock and router tests

My timezone test is one record scheduled for exactly 12:00 PM. I create it in Airtable and check the Google Calendar event immediately. Then I move it to 3:30 PM and run the update.Test the same workflow with a DST date because a setup that looks correct in one month can expose a timezone mistake later in the year.

The source setup used a Pacific timezone example, but the actual value should match your Airtable base. In Make, date functions can parse and format a date with a named timezone. A pattern like this is useful when the incoming value needs an explicit timezone:

formatDate(
  parseDate(Airtable_Start_Date; "YYYY-MM-DD HH:mm:ss"; "America/Los_Angeles");
  "YYYY-MM-DDTHH:mm:ssZ";
  "America/Los_Angeles"
)

Replace the timezone with the one your Airtable base uses. Test the output in the Make bundle before you touch Google Calendar. If the bundle shows the expected offset, the Calendar module has a clean value to work with.

The Make workflow has three jobs

The current Make Airtable module uses polling when you choose a watch-style trigger. Make describes these as scheduled checks for new or changed data. You can choose where the first run starts, then later checks look for records changed since the previous run. citeturn306175search5turn306175search6

From there the workflow has three jobs: find changed Airtable records, decide what should happen to the Calendar event, and write the result back to Airtable.

Set up the Airtable Watch Records module with the base and table you are using. Use Last Modified Time as the trigger field. On the first run, use Make's Choose where to start option or run the module with a known record so you can inspect the bundle. Make's documentation recommends this approach for polling triggers when you need sample data. citeturn306175search5

Once a bundle arrives, I check two values before sending anything to Google Calendar: Calendar Event ID and Archived.

There are only three paths

New Airtable record, Calendar Event ID is empty, Archived is false: create the Calendar event.

Existing Airtable record, Calendar Event ID has a value, Archived is false: update that Calendar event.

Archived is true and Calendar Event ID has a value: delete the Calendar event.

A Router after the Airtable trigger handles these three branches. The filters stay narrow because the wrong filter here is what creates duplicate events.

New record: create the event

Add Google Calendar and choose Create an Event. Pick the exact calendar you want. If you have several calendars under the same Google account, select the one by name instead of assuming the default calendar is correct.

Map Event Title to the Calendar event name. Map Start Date and End Date to the corresponding Calendar fields. Add the Airtable record ID to the event description if you want a visible reference back to the source record.

Then write the Google Calendar Event ID back into Airtable with Update a Record. The Record ID comes from the Airtable trigger. The Calendar Event ID comes from the Create Event module.

The filter for this branch is:

Calendar Event ID → does not exist
Archived → is not checked

Without that first condition, every change to the Airtable record can create another calendar event.

Existing record: update the same event

The second branch uses Google Calendar's Update an Event action. Pass in the Calendar Event ID stored in Airtable. Then map the current title and dates again.

Its filter is:

Calendar Event ID → exists
Archived → is not checked

I can change the title, move the deadline or extend the end time in Airtable and the existing Calendar event changes with it.

Archived record: remove the Calendar copy

I stopped deleting Airtable records after the Calendar event had been created. The Archived checkbox is cleaner for this job. Make sees the checkbox change because the record was modified. The third Router path then calls Google Calendar Delete an Event with the stored Event ID.

After the delete succeeds, clear Calendar Event ID in Airtable. It leaves the record in a known state and stops another update from trying to delete an event that no longer exists.

The polling math changed

The old version of this article suggested that a 15-minute schedule stayed inside Make's 1,000-operation free allowance. That calculation was wrong.

Make counts a trigger module run as an operation when it checks for new data. Make's current operations documentation also explains that later modules can consume extra operations for every bundle they process. citeturn306175search10

Those figures are trigger checks only. Calendar writes and Airtable updates add more usage. For a small base on a low-cost plan, hourly polling can keep idle checks low. For a busy team that needs changes within seconds, polling is the wrong trade-off.

When a webhook makes more sense

Airtable has a Webhooks API that can notify another system about record changes in real time. Airtable documents it as a way to receive notifications when records are created, fields are changed, or records move in or out of a view. citeturn306175search1

For a fast sync, a Custom Webhook can replace a Watch Records check every minute. The Make side starts with a Custom Webhook. Airtable sends the record change to that URL. The rest of the Calendar routing can stay the same.

Polling works when a delay of five to sixty minutes is fine and the table changes only a few times each day. It costs less and has fewer moving parts. I move to webhooks when people expect the Calendar event to appear right after they save the Airtable record.

The duplicate event test

I create one Airtable record and wait for the Calendar event. Then I change the title three times and move the time twice. After every run, I count the Calendar events linked to that record. The result should stay at one.

Then I clear the Calendar Event ID manually and run the record again. That creates a second event, which is exactly why the ID field matters. I delete the test duplicates and restore the original ID.

I had tested a broken Event ID. I replace it with a fake value and let the Update Event module run. Google Calendar returns a 404 because the event cannot be found. The workflow should catch that error and clear the bad ID so the next valid run can create a fresh event.

One case: someone deletes the Calendar event manually

This happens. A team member opens Calendar, deletes an event and forgets that Airtable still contains its ID. The next Airtable edit sends that old ID back to Google Calendar and the update fails.

I handle this with an error route on the Calendar update module. When the response is a 404, the route clears the Calendar Event ID in Airtable. The next Airtable change then goes through the create branch.

I don't use an unconditional Ignore handler for this. Ignoring the error hides the missing event and leaves the Airtable record pointing at something that no longer exists. Clearing the bad ID gives the record a usable state again.

Another case: missing dates

People often create Airtable records before they know the final deadline. If the Start Date is empty, the Calendar module has nothing to create.

I put a filter before the create and update paths:

Start Date → exists
Start Date → is not empty

For a table where dates are optional, I also keep a small "Needs Date" Airtable view. The record stays in Airtable until someone fills the missing date. The sync does not send half-finished records to Calendar.

What I changed after the first build

The first version had more fields than I needed. I removed Duration because an End Date was already available. I removed a separate "Synced" checkbox because Calendar Event ID tells me if an event exists. I kept Archived because it represents an action a person can take in Airtable.

I stopped putting long notes into the Calendar event description. The event is used for the date and basic context. Airtable holds the full project information. That keeps Calendar readable when someone opens a busy day on their phone.

One more change saved me from a lot of confusion: I added the Airtable record name and ID to the Calendar description. Six months later, I can open the event and trace it back to the exact Airtable record without searching the whole base.

My test list before I turn the sync on

• New record creates one Calendar event.
• Title change edits the same event.
• Start time change moves the same event.
• End time change updates the event.
• Archived record deletes the Calendar event.
• Missing date stays out of Calendar.
• Invalid Calendar Event ID gets cleared after a 404.
• Timezone test shows the same local time in Airtable and Calendar.
• Repeated Airtable edits never create duplicate events.
• Polling frequency stays within the Make operations budget.

Where this setup dont work

This design works well when Airtable is the place where one team maintains dates and Google Calendar is the place where people see them. It gets harder when people also edit the Calendar events and expect those edits to flow back to Airtable.

You need a second direction, a way to identify the Airtable record from the Calendar event, and rules for deciding which edit wins when both systems change. I have not put that into this workflow because it turns a clean one-way sync into a conflict-resolution system.

Avoid a minute-by-minute polling setup for a base with thousands of changes when the team has access to an event-driven webhook design. The math gets expensive fast, and the Calendar does not need to be checked every minute if a webhook can tell Make about the change.

The setup I use

The Airtable table carries the event information and the Calendar Event ID. Make watches for changes, routes records by their state, writes to Google Calendar and stores the returned ID. An Archived checkbox handles deletion. A timezone test catches the most annoying display problem before the workflow reaches real users.

The flow is small:

Airtable
   ↓
Watch Records
   ↓
Router
 ┌───────────────┬────────────────┬─────────────────┐
Create          Update           Archived
 ↓               ↓                 ↓
Google Calendar  Google Calendar   Google Calendar
Create Event     Update Event      Delete Event
 ↓               ↓                 ↓
Airtable ID      —                Clear Airtable ID

I have used this pattern for content calendars and departmental schedules because the ownership stays clear. Airtable is where the team changes the work. Calendar shows those changes to everyone who plans their day there.

Before turning it on, I check the one thing that caused the original missed deadline: can a person change an Airtable date at 10 AM and see the correct event in Calendar without someone copying it by hand?.

Check also: Make.com Error Handling: How to Set Up Fallback Routes and Email Alerts