How to Connect Webflow to Airtable, Notion, and Google Sheets

TL;DR: A Webflow Airtable integration has four working routes, and the same four carry Notion and Google Sheets. The right one is decided almost entirely by how often the data changes and how many rows you are moving. A one-off migration belongs in a CSV import. A living dataset belongs in a sync app or a scheduled script that respects Webflow's published API rate limit of 60 or 120 requests per minute depending on the site plan. The four routes are:

• CSV import into a Collection, for one-off migrations and bulk edits of existing items.
• A marketplace sync app such as Whalesync, for a continuous two-way link you do not want to maintain yourself.
• An automation platform such as Zapier or Make, for event-driven, one-directional pushes.
• A custom script against the Webflow Data API, for anything with unusual field logic or a schedule you control.

The rest of this guide gives the setup path for each route, the rate limit each one runs into, the field types that silently fail to map, and the failure modes I see most often on client builds.

What is the fastest way to connect Webflow to Airtable, Notion, or Google Sheets?

The fastest working connection between a spreadsheet and the Webflow CMS is a CSV import, because it needs no account linking, no API token and no third-party app review. Webflow's own import documentation names the three source tools directly, telling you to "build your own CSV using a tool like Google Sheets, Microsoft Excel, or Airtable". The CSV route stops being the right answer the moment the data changes on a schedule.

In the projects I run for agencies, the question I ask first is not "which tool" but "who edits this row next week". If the answer is nobody, import the CSV and move on. If the answer is a client marketer working in Airtable every Tuesday, a one-way import will be stale within a sprint and you need a real sync. The four setup paths below are ordered from least to most engineering effort.

How do you import a CSV into a Webflow Collection?

A CSV import loads rows straight into a Collection from the CMS panel, and it also updates existing items when the file carries their Item IDs. Webflow caps the upload at 4 MB per file, and the header row does not count as a Collection item. The number of items you can import depends on the site plan.

1. Export the Collection first if you are updating existing items, so the file carries the Item ID column Webflow matches on.
2. Open the CMS panel, choose the Collection, and click Import.
3. Drag in the CSV, confirm whether the first row is the header row, and click Continue.
4. Choose whether to import into all locales or only the current locale.
5. Choose Link and update matching items and import remaining as new, or Import all as new items.
6. Map each column to an existing field, create a new field for it, or set it to Do not import, then click Import and stay in the Designer until every item finishes.

How do you set up a two-way Airtable to Webflow sync?

A two-way sync between Airtable and Webflow is set up by installing a marketplace app that holds a persistent link between a Collection and an external table, so edits flow in both directions without a scheduled job. Whalesync is one such app in the Webflow Apps marketplace, described on its listing as "2-way sync your Webflow CMS with Airtable, Notion, or Google Sheets". Before committing to any app in this slot, settle whether it syncs both ways or only pushes one way, and whether it covers the field types your Collection actually uses, because multi-reference and rich text are where these tools differ most.

1. Install the app from its Webflow marketplace listing, which sends you through Webflow's authorisation screen.
2. Read the permission scopes the app declares, then choose whether to grant them for specific sites or for the whole Workspace. Webflow's authorisation screen lets a user "authorize access to specific Webflow Sites or a Workspace", and the scopes apply to everything the grant covers, not just the Collection you are syncing.
3. Connect the Airtable base, Notion database or Google Sheet on the app's side.
4. Choose which Collections take part, then map each Collection field to a column, leaving unmapped anything the sync should not own.
5. Run a small test batch of five or ten rows before pointing the sync at a full table.

How do you push Airtable records to Webflow with Zapier or Make?

An automation platform fires a Webflow action when something happens elsewhere, such as a new Airtable record creating a Collection item. Webflow itself points users of the retired Logic feature toward Zapier and Make for that kind of work. Which of those two suits an agency better is covered in my guide to the Webflow tech stack.

1. Pick the trigger on the source side, such as a new or updated Airtable record, and give it a view or filter narrow enough that it does not fire on every edit.
2. Add the Webflow action, authorise the connection, and select the site and Collection.
3. Map each field, and decide explicitly whether the action creates a draft or a live item.
4. For the reverse direction, use a Webflow webhook rather than polling. Webflow's own guidance is that webhooks "allow your application to receive real-time updates without the need for continuous API calls".

How do you write CMS items with the Webflow Data API?

A custom script calls the Webflow Data API directly, which is the only route that gives you full control over batching, retries and field transformation. The bulk endpoint accepts up to 100 items per request, so a script can move far more content per minute than a click-driven tool that sends one item at a time.

1. Create a Site token or an OAuth app with the CMS:write scope, and keep it out of the repository.
2. Read the Collection schema first, because every write is keyed by field slug rather than field label.
3. POST batches of up to 100 items to /v2/collections/{collection_id}/items/bulk with a Bearer token, sending each item's values inside fieldData.
4. Handle HTTP 429 by reading the Retry-After header rather than sleeping on a fixed timer.
5. Publish once at the end of the run instead of after each batch.

What are the API rate limits for Webflow, Airtable, Notion, and Google Sheets?

Webflow's Data API allows 60 requests per minute on Starter and Basic site plans and 120 requests per minute on the plans its documentation still calls CMS, eCommerce and Business, with Enterprise negotiated separately. Airtable allows 5 requests per second per base, Notion allows an average of three requests per second per connection, and the Google Sheets API allows 300 read requests per minute per project. Converting those to a single unit, which is arithmetic I did rather than a figure any of the four vendors publishes, the Webflow API is the narrowest pipe in three of the four pairings. The exception is Google's per-user-per-project quota, which works out to the same 1 request per second as Webflow's Starter and Basic tier.

Two details on the Webflow side matter more than the headline number. Webflow applies its limit per API key, so two integrations on separate tokens do not compete with each other. And Webflow returns X-RateLimit-Limit, X-RateLimit-Remaining and Retry-After headers on every call, which is what a well-built sync should be reading instead of guessing.

Platform	Published rate limit	Per second (calculated)	What happens when you exceed it
Webflow Data API, Starter and Basic	60 requests per minute	1 (our calculation)	HTTP 429 with a Retry-After header, typically 60 seconds
Webflow Data API, CMS / eCommerce / Business	120 requests per minute	2 (our calculation)	HTTP 429 with a Retry-After header, typically 60 seconds
Airtable Web API, per base	5 requests per second	5 (published as such)	HTTP 429, then a mandatory 30 second wait
Airtable Web API, per personal access token	50 requests per second	50 (published as such)	HTTP 429, then a mandatory 30 second wait
Notion API, per connection	3 requests per second on average	3 (published as such)	HTTP 429, or HTTP 529 when Notion is overloaded
Google Sheets API, per project	300 read and 300 write requests per minute	5 (our calculation)	HTTP 429, quota refills the next minute
Google Sheets API, per user per project	60 read and 60 write requests per minute	1 (our calculation)	HTTP 429, quota refills the next minute

One more number is worth carrying in your head. Because the Webflow bulk endpoint takes up to 100 items per request, a site on a 120 requests per minute plan has a theoretical ceiling of 12,000 items per minute. That multiplication is mine, not Webflow's, and no real sync gets near it, because error handling, field validation and the publish step all eat into it.

When is a CSV import better than a live sync?

A CSV import beats a live sync whenever the content stops changing after launch, because a sync you never edit is a standing OAuth grant and a monthly bill for no benefit. Webflow caps the CSV upload at 4 MB per file, which in practice is thousands of text-only rows and far fewer rows once rich text is involved. When I migrate a client's legacy blog, the CSV route is almost always correct, and the sync question only comes back if the client actually writes in Notion.

The import is also the cleanest way to make bulk changes to items that already exist. Webflow matches uploaded rows to existing Collection items using the Item ID column that comes out of a Collection export, so exporting, editing in a spreadsheet and re-importing just the changed rows overwrites the old values without touching anything else.

• Choose CSV import when the dataset is final, or when you are editing existing items in bulk and can round-trip through an export.
• Choose a sync app when a non-technical person owns the content and will keep editing it in Airtable, Notion or Sheets.
• Choose an automation platform when the trigger is an event rather than a schedule, such as a form submission creating a record.
• Choose a script when field logic is unusual, when you need control over batching, or when the source is neither a spreadsheet nor a database.

How do you map spreadsheet columns to Webflow CMS fields without losing data?

Mapping spreadsheet columns to Webflow CMS fields without losing data means formatting each column into the shape its target field accepts before the import runs, because several Collection field types take only a specific format and Webflow drops the value rather than failing loudly. Webflow publishes the accepted format for every field type in its CSV import documentation, and the four types below account for nearly every mapping problem I find when auditing an inherited import. How many Collections a site should have in the first place is a separate question, covered in my guide to Webflow CMS structure.

Reference and multi-reference fields

Reference fields match on the target item's slug, not its name, and Webflow converts your plain text into a slug before looking for a match. A row reading "Charles Dickens" resolves to charles-dickens, so an item with a custom slug like charles-d will never match. Multi-reference values are separated by semicolons. The workaround is to hold the referenced item's real slug in its own column in Airtable or Sheets, and map that column rather than the display name.

Image and multi-image fields

Image fields take a direct URL ending in a supported extension, and Webflow states that images brought in this way "don't get responsive image variants (srcset and sizes)". Every image you import by URL therefore ships at one size to every device; what that costs a page is covered in my Webflow QA checklist. Webflow's own remedy is to "use images that are already sized and optimized, or upload them directly in Webflow instead", so resize before import or accept a manual upload pass for anything above the fold.

Option and switch fields

Option fields build their choice list from the unique values in the column, up to a documented maximum of 100 options, and every stray spelling in the source becomes its own option. Switch fields need exactly two unique values in the column, and you pick which of the two means "Yes" during the mapping step. The workaround for both is to normalise the source column to a small closed set before importing, and to map anything with an open-ended value list to a plain text field instead.

File fields

File fields cannot be filled from a CSV at all. Webflow's own mapping table says plainly that "no data maps to the file field" and that you should upload files manually after the rest of the data imports. Plan that manual pass into the estimate before you promise a client a single-click migration of their PDF library, because it is the one part of the job no route on this page automates.

What breaks first when a Webflow sync goes wrong?

A Webflow sync breaks first on an unmatched reference field, on the Airtable monthly call cap, on a third-party app spending the same quota as your own script, on the site publish throttle, or on a stale ID map left behind by a backup restore. The API rate limit is rarely the culprit, because every serious sync tool backs off automatically. The expensive failures are the quiet ones, where content lands in a state nobody notices for a week.

• Reference mismatch downgrades the row to Draft. Consequence: the item exists in Webflow but never appears on the live site. Webflow documents that a row whose required reference field is empty or unmatched "imports as a Draft with the reference field left blank". Fix: put the referenced item's real slug in the source column, not its display name.
• The Airtable monthly cap fires instead of the rate limit. Consequence: every request returns 429 even when the sync is idle, which reads like a broken token. Airtable's Free plan allows 1,000 API calls per workspace per month, and exceeding it opens a one-time 30 day grace period after which calls over the limit are blocked until the month resets. The Team plan allows 100,000 calls per month and then slows to 2 requests per second instead of blocking. Fix: check the Usage tab of the workspace holding the base being called, not the workspace you happen to have open.
• Third-party apps spend the same quota you do. Consequence: a sync app and your own script starve each other on the same Airtable workspace. Airtable states that requests from third-party integrations "consume the same monthly Public API quota as your own API calls". Fix: give each integration its own workspace or its own service account before you scale the row count.
• The publish step throttles, not the write step. Consequence: items save but never go live, so the CMS looks correct and the site does not. Webflow limits Site Publish operations to one successful publish per minute. Fix: write all items first, then publish once at the end of the run, never per row.
• A restore invalidates the ID map. Consequence: the sync creates duplicates instead of updating, because the IDs it stored no longer point anywhere. The mechanics of what a restore changes are covered in my guide to auditing an inherited Webflow site. Fix: re-establish the mapping from a fresh Collection export before re-enabling the sync.

How do you keep a sync inside its rate limits?

Keeping a Webflow sync inside its limits comes down to batching writes and reading the response headers rather than sleeping on a fixed timer. Webflow's bulk endpoint accepts up to 100 items in a request, and Airtable's batching "can handle up to 10 records per request, enabling you to update up to 50 records per second". On the projects I lead, the rule is that any sync moving more than a few hundred rows must batch, because a per-row loop will hit a 429 long before it finishes.

Reads are cheaper than most people assume. Webflow states that for cached requests to its content delivery API "there are effectively no rate limits", and only uncached origin requests count against the plan. Google's Sheets API counts each batch request, including any subrequest, as one API request against the 300 per minute project quota.

• Batch every write to the platform's documented maximum before adding any delay logic.
• Read X-RateLimit-Remaining and Retry-After on Webflow responses and back off on the header, not on a guess.
• Retry Notion on both 429 and 529, since 529 means Notion is temporarily overloaded rather than that you overused your own quota.
• Keep Google Sheets payloads near the recommended 2 MB maximum and well inside the 180 second per-request processing timeout.
• Watch the Google Sheets billing note, which says exceeding the quota "is planned to incur charges to your Google Cloud billing account later in 2026".

What should you check before installing a Webflow sync app?

Before installing any Webflow sync app on a client Workspace, read the permission scopes on its marketplace listing, because approving an app is a security decision rather than a convenience one. Webflow's app listings carry an "Approved by Webflow" badge whose own small print reads "We do not endorse or certify these apps", which means the badge signals a quality review and not an endorsement of how the app handles data.

The scopes are more revealing than the marketing copy. The Whalesync listing declares seven of them, including read and write access to CMS data, to page data, to site data and publishing, to user accounts, site users and access groups, and to the Ecommerce store, plus read access to site forms and submissions. A CMS sync that can also read form submissions is a wider grant than most agencies think they are approving.

• Read every declared scope on the listing and compare it against what the sync actually needs to do.
• Install on a staging site first, so the first authorisation is not on the client's live Workspace.
• Record who installed the app and when, because the grant outlives whoever set it up.
• Remove the app at handoff if the client is not going to keep using the sync.

Want a second opinion before you wire up a client's CMS?

If you are choosing between a CSV migration, a sync app and a custom script for a client's Webflow build, I am happy to look at the actual Collection schema with you. In a 15 minute call we can go through your field types, flag the ones that will not map cleanly, and settle on the route with the least maintenance for the way your client actually works.