Sync Airtable and Notion Automatically

“Sync” is the word that kills these projects. It sounds like one thing and is in fact two, with wildly different costs, and almost everybody who asks for the expensive one actually needs the cheap one.

So before any of the mechanics: decide whether you want a mirror or a sync. A mirror is one-way. One tool is in charge, the other shows a copy, and when they disagree the copy is wrong by definition. A sync is two-way, both sides can change, and something has to decide what happens when they change the same thing. That decision is the entire difficulty, and no amount of clever tooling removes it.

Why two-way is so much harder than it sounds

Three problems arrive together, and none of them show up in a demo with five rows.

The echo

You write a change from Airtable into Notion. Notion notices a record changed and tells your workflow. Your workflow writes it back to Airtable. Airtable notices a record changed. Congratulations: an infinite loop, burning your API quota, at three in the morning.

Every two-way sync needs loop protection, and the usual fix is a fingerprint: before writing, compare the incoming value with what is already there and do nothing if they match. It sounds trivial and it is not — a field the other system reformats on save (a date, a phone number, rich text) never matches, so it echoes forever. Normalise both sides before comparing, and test specifically with the fields that get reformatted.

The conflict

Two people edit the same record in the two tools within the same sync interval. One edit is about to be destroyed. The default answer is last-write-wins, which is not a strategy so much as a way of deciding not to have one — and the person whose work vanishes has no idea it happened.

The answer that works in practice is not clever merging. It is ownership per field: status is owned by Notion and Airtable never writes it; the client name is owned by Airtable and Notion never writes it. Now there is no conflict to resolve, because two systems are never in charge of the same thing. Almost every “we need two-way sync” turns into this once you go field by field, and it is a much smaller build.

The deletion

A record disappears from one side. Was it deleted, archived, moved out of the view you are watching, or did a filter change? You usually cannot tell from the API, and each possibility wants a different response.

My rule: a sync never deletes. It marks the other side as missing or archived and leaves a human to decide. An automation that can delete records is one bad filter away from clearing a database, and nobody discovers that on the day it happens.

The mapping table you cannot skip

Airtable record IDs and Notion page IDs have nothing to do with each other, so something has to remember that recXXX is the same thing as that page. People try to avoid keeping that mapping by matching on a name or an email instead, and it works until two records share a name, or somebody fixes a typo and the link silently breaks into two records.

Keep an explicit mapping: a field on each side holding the other’s ID, or a small table in the middle. It is five minutes of work that removes an entire category of bug.

Fields that cannot be written, and fields that lose their shape

The two tools do not have the same type system, and the mismatches are specific.

Computed fields are read-only. Airtable formulas, rollups, lookups, autonumber and created-time cannot be written to. Neither can a Notion formula or rollup. If one of those is in your mapping, the sync will fail on it every single time — and the right response is to recompute on the destination, not to try harder.
Rich text degrades. Notion pages are blocks, with nesting, toggles, embeds and children. An Airtable long-text field is a string. Round-tripping loses formatting, and the loss is not symmetrical, so a field that goes back and forth repeatedly gets progressively flatter.
Select options must exist first. Writing a status value the destination has never seen either errors or silently creates a new option, and after a month you have “In progress”, “in progress” and “In Progress” as three different states.
Relations point at records, not text. A linked record has to be resolved to an ID on the other side, which means the thing it points at must be synced first. Order matters.

Write the field map out as a table before building — name, direction, owner, type on each side. The fields that cannot survive the trip become obvious on paper, which is a much cheaper place to discover them.

Rate limits, and why sync jobs hit them

Both APIs throttle, and a sync is exactly the shape of workload that trips them: hundreds of small reads and writes as fast as the loop can go.

Airtable allows 5 requests per second per base on every plan, and once you exceed it you get a 429 and must wait 30 seconds before anything succeeds — a genuinely punishing penalty, because a naive retry loop keeps re-triggering it and the job never recovers. Notion works differently: a request budget per 60-second window, per connection and per workspace, varying by plan, rather than a flat per-second ceiling. (Both checked September 2026 — re-check them before relying on the numbers, because this is exactly the kind of detail that changes.)

What that means in practice: pace the requests deliberately rather than running flat out, use batch endpoints where they exist, and back off properly on a 429 instead of retrying immediately. And prefer changed records only over re-reading everything — a nightly full scan of a 10,000-row base is both slow and the fastest route to a quota error. Whether that means webhooks, polling a modified-time field, or a schedule is the usual trade-off, covered in webhook vs polling vs schedule.

What a working build looks like

For most businesses, the thing that actually gets built and keeps running is:

One system of record per entity. Projects live in Notion; clients live in Airtable.
A one-way mirror in each direction for different fields, with an owner per field, so nothing is ever written by both.
An explicit ID mapping, and no deletions — only an archived flag.
Changed-records-only reads, paced under the rate limits, with backoff.
A failure alert that names the record and the field, because “sync failed” tells you nothing at nine on a Monday. See error handling for automations.

Notice that this is technically two mirrors rather than a sync. It behaves like a sync to everyone using it, and it has no conflict resolution in it at all, which is why it survives.

When not to sync

Three cases where the honest answer is don’t.

When the real problem is that nobody agreed which tool to use. A sync between two tools that overlap by ninety percent is an expensive way to avoid a ten-minute conversation, and it doubles the maintenance forever. Pick one. Migrate. It is cheaper, in the first month, than the sync is.

When a link would do. If people just need to see the other thing, a link in a field beats a copy of the data. Nothing to keep current, nothing to break.

When the built-in integration already covers it. Both tools ship connectors and embeds that change as the products change. Check what exists before commissioning anything — and if a tool like Make or Zapier handles your case with a template, use it. I have written honestly about where those win over a custom build in n8n vs Make; a two-database sync at small volume is often exactly that case.

What it costs

A one-way mirror — one entity, a mapped field set, changed-records-only, error alerts — is a single workflow starting at $600. Several entities with owned fields in both directions, ID mapping and archive handling is $1,800-tier work. Both on the pricing page, both with 30 days of support after launch.

Built on n8n, in your own accounts on your own API keys, handed over with the exported workflow, the field map and a runbook. The field map is the deliverable people end up valuing most, because it is the document that says who owns what.

Book a free intro call and bring the field list. Half of these conversations end with a smaller project than the one that was requested, which is the point of having them.

Key takeaways

Mirror or sync? One-way is a fraction of the cost, and an owner per field usually removes the need for two-way entirely.
Two-way needs loop protection, and the fields that get reformatted on save are what breaks it.
Keep an explicit ID mapping. Matching on names breaks the first time somebody fixes a typo.
A sync never deletes. It flags, and a human decides.
Formulas and rollups cannot be written to; rich text degrades on every round trip. Write the field map before writing any code.

How to Sync Airtable and Notion Automatically (Without Breaking Both)