Framer's Notion plugin failed to sync: what it means and how to fix it

Start here: find your error message

The plugin shows failures as a toast in the Framer editor. The wording tells you which of seven things went wrong, so it is worth reading exactly rather than retrying blind. These strings come from the plugin's source code as of September 2026.

Work down the causes in order. The first two account for the large majority of failures, and both are fixed in Notion rather than in Framer.

Cause 1: a duplicate or empty slug (most common)

Framer CMS requires every item in a collection to have a unique, non-empty slug. The plugin checks this before it writes anything, so one bad row stops the entire sync — including the fifty rows that were fine. This is the single most frequent reason a sync that worked last week stops working today: someone added a row and left the slug blank, or duplicated an existing row.

The error text tells you which values are at fault. A duplicate names the repeated slug; a missing slug names the row positions, counting from the top of the database.

• Check for blanks: in Notion, sort the database by the property you mapped to the slug. Empty values sort together at one end.
• Check for duplicates: group by the slug property. Any group with a count above one is a duplicate. Two rows called "About" produce the same slug even though the rows are different.
• Check for slugs that empty out: a value made only of punctuation, emoji, or non-Latin characters can slugify to an empty string, which counts as missing. Give those rows an explicit Latin slug.
• Do not use the title as the slug on a collection where titles repeat: add a dedicated text property for the slug, fill it for every row, and map that instead.

Fix the rows in Notion, then sync again. Because nothing was written on the failed attempt, there is no half-synced state to clean up.

Cause 2: the integration lost access to the database

Notion connections are granted per page, not per workspace. The plugin can only read a database that has been explicitly shared with the Framer integration (Notion's own explanation). When that connection goes away, the plugin shows the "does not have access" screen with a Retry button.

There are three ordinary ways it goes away, and none of them look like a change to the person who did it:

• Someone removed the connection. Open the database in Notion, click the ••• menu, and look under Connections. The Framer integration should be listed. If it is not, add it again.
• The database was duplicated. A duplicate is a new database with a new ID and no connections of its own. The plugin is still pointed at the original. Either connect the integration to the duplicate and re-select it in the plugin, or go back to using the original.
• The database moved to a different workspace or teamspace that your Notion account cannot reach. Check you are signed in to Notion with the account that has access, then use Retry.

One consequence worth knowing before you debug this: the sync removes CMS items whose Notion rows it can no longer see. That is how deletions in Notion reach Framer, but it also means rows that were archived or moved out of the database will disappear from your published collection on the next successful sync. Check Notion before assuming the plugin lost your content.

Cause 3: the Notion authorization expired

If Notion returns 401, the plugin deletes the token it had stored and closes with Notion Authorization Failed. Re-open the plugin to re-authorize. Nothing is broken; the plugin simply needs to be authorised again.

Reopen the plugin and sign in. The trap is which account you pick: authorising with a personal Notion account that cannot see the team database produces an immediate "no access" error that looks like Cause 2 but is really this one. Make sure the workspace shown in the Notion permission screen is the workspace the database lives in.

Cause 4: a Notion property type Framer cannot map

The plugin maps a fixed list of Notion property types onto Framer CMS field types. Anything outside that list throws Property type '…' is not supported., and mapping a supported property to the wrong field type throws Field type '…' is not valid for property type '…'.

As of September 2026 the plugin accepts: title, rich text, number, checkbox, date, created time, last edited time, select, status, URL, email, phone number, files, relation, unique ID, and formula.

Types that are not in that list — including multi-select, rollup, people, created by, and last edited by — cannot be mapped at all. If your content depends on one, the usual workaround is to add a formula or rich text property that renders the value as text, and map that instead.

Select and Status are the awkward case: they map fine, but the option list is captured once when the field is created, so a value added in Notion later resolves to the wrong thing rather than erroring. Why Select fields stop showing correctly covers that separately, because it fails silently instead of producing any of the messages above.

Cause 5: a renamed, deleted, or newly added property

Renaming a property in Notion does not rename it in the plugin's saved mapping; the mapping is stored against the property's id and its name. If the property you chose as the slug is renamed or deleted, the sync stops with No field matches the slug field id "…". Sync will not be performed. and nothing is written.

Newly added properties have their own version of this. Issue #331 reports imports finishing with a success toast while the Data panel keeps showing the old field names and never lists properties added since setup. The content synced; the mapping did not refresh.

In both cases the fix is to re-open the plugin, run Manage → Import, and re-map the fields — choosing the slug property again explicitly. If the Data panel still shows stale names, re-selecting the data source forces the field list to rebuild.

Cause 6: Notion rate-limited the sync

Notion allows roughly three requests per second per integration (Notion's request limits). The plugin paces itself and, since this change, backs off and retries when Notion answers 429. If it is still being refused after its retries, it gives up with Max retries exceeded.

This shows up on large databases, on pages with many images, and when two syncs run at once. It is a transient failure, not a configuration problem.

• Wait a minute and sync again rather than retrying immediately — retrying straight away extends the rate limit window.
• Sync one collection at a time. Two collections syncing in parallel share the same integration and the same three-requests-per-second budget.
• Check whether anything else uses the same Notion integration at the same time, such as another automation.
• For very large databases, splitting the content across two databases syncs more reliably than one database of several thousand rows.

Cause 7: it reported success and nothing changed

This is the frustrating one, because there is no error to search for. There are four separate explanations, and they are worth checking in this order.

• The item looked unchanged. The plugin only re-fetches page content for rows whose Notion "last edited time" is newer than the last successful sync. Editing a property usually updates that timestamp; some changes do not. Formula and relation values are re-synced every time precisely because they change without touching the timestamp. To force a row through, make a trivial edit to it in Notion and sync again.
• Some items failed while others succeeded. The plugin writes the rows that worked and logs the rest to the browser console as N items failed to sync: with their ids. Open the developer console before syncing to see them. Since this fix the sync no longer marks failed items as up to date, so they are retried on the next run instead of staying silently stale.
• The field is a known gap. Image-type fields have been reported to stay empty after a "sync complete" toast (issue #245), and divider blocks are dropped from synced page content (issue #200). If one specific field type is the only thing not arriving, check the plugin issue tracker before debugging your own setup.
• You are looking at the wrong state. Synced items can sit as drafts in the collection. Check the CMS list rather than the published site, and confirm the item is published before concluding the sync failed. If the item is correct in the collection but stale on the live site, the sync worked and the publish did not — that is a separate problem.

What the plugin does when a sync fails

Knowing the failure behaviour saves you from fixing things that are not broken:

• Slug errors abort everything. The check runs before any write, so a failed sync leaves the collection exactly as it was.
• Per-item errors are partial. Rows that succeeded are written, rows that failed are skipped and logged, and the sync checkpoint is not advanced — so the next sync retries them.
• Rows the sync cannot see are deleted. Items in the Framer collection with no matching Notion row are removed. This is intended behaviour for deletions, and a trap for archived or moved rows.
• Authorization failures close the plugin. The stored token is cleared, so the next open starts at the sign-in screen.
• Closing the plugin mid-sync cancels it. Framer warns you first. A cancelled sync leaves whatever was already written in place.

If none of that fixed it

In order, and stopping as soon as it works:

• Open the browser developer console, sync again, and read the errors. The plugin logs far more there than it shows in the toast, including the ids of individual failed items.
• Try the same Notion database against a brand-new, empty Framer CMS collection. If that works, the problem is in the existing collection or its saved mapping rather than in Notion.
• Try a three-row copy of the database. If the small one syncs and the real one does not, you are looking at rate limiting or one specific bad row, not a broken setup.
• Search the framer/plugins issue tracker for your exact error text. The Notion plugin is developed in the open, and several silent-failure bugs are tracked there with workarounds.
• If it is reproducible and not already filed, open an issue there, or contact Framer support for anything account or billing related.

If you need this to stop breaking

Most of the causes above are not really plugin bugs. Slugs, permissions, and property types are Notion-side facts, and they would break any tool that syncs Notion into a CMS — including ours. No product fixes a duplicate slug for you.

What does differ is when you find out. The official plugin syncs only while a collaborator has it open in the Framer editor, and automatic syncing has been an open request since October 2024 (issue #75). On a site you have handed to a client, that means a failure sits undiscovered until the next time someone opens the project — which may be the day the client asks why their update is not live.

KnotCMS runs the sync on its own servers instead: on paid plans it checks Notion once a minute and reconciles the collection without anyone opening Framer, and a failure surfaces at the time it happens rather than at the next manual sync. It is a paid tool and it is ours, so treat that as the disclosure it is — the engineering write-up covers how the pipeline handles the same failure modes, and the documentation covers setup. If Framer's free plugin is working for you, keep using it; the comparison is honest about when it is the better choice.

Common questions