The Notion v3 node in n8n: migrating to Data Sources without breaking your workflows

An n8n workflow that has been reading from or writing to Notion for months without any changes on your end can suddenly stop working, with not a single line of code touched on your side. The cause isn't n8n: Notion overhauled the underlying structure of its databases deeply enough to break compatibility with the old node. n8n responded with a v3 of the Notion node, compatible with this new API — but migrating an existing workflow requires understanding what actually changed, not just bumping a version number.

Why your Notion workflows might break without warning

Historically, a Notion database had a single source of content: its identifier (database_id) was enough to unambiguously reference it. Notion introduced multi-source databases: a single database can now group several distinct data sources, each with its own identifier. This change, which arrived with a new version of the Notion API, isn't backward-compatible with the old way of querying a database by its database_id alone.

The problem was reported publicly in n8n's GitHub repository: the moment a Notion database switches to multi-source, creating a page, reading it, or writing a relation property with the old node either fails silently or returns an error, since the integration was still pointed at an earlier API version incompatible with this new behavior. In practice, a workflow that had been running fine for months can stop working overnight — not because you changed it, but because the underlying Notion database changed structure on Notion's side, outside your direct control.

What actually changes in the Notion API

Three changes deserve particular attention during a migration:

• database_id is no longer enough to query or create a page in a multi-source database: you now need to designate a specific data source (data_source_id), since a database can contain several.
• The archived field, which flagged a page as deleted, is renamed in_trash — any Code node or n8n expression still filtering on archived stops working correctly without raising a visible error, which makes it a particularly sneaky trap.
• The transcription block type is replaced by meeting_notes; a workflow that generates or reads this specific block type (a meeting transcript synced from Notion downstream of a pipeline like the one described in our meeting transcription and summarization with Whisper guide) needs to be updated accordingly.

What the v3 Notion node brings to n8n

Rather than a minimal compatibility patch, n8n gave the Notion node a deep overhaul.

• A new Data Source resource (Get and Search operations) lets you explicitly list and select the right data source within a multi-source database, instead of guessing an identifier.
• Markdown read and write operations for pages and blocks, which avoid manually rebuilding Notion's block structure block by block for simple text content.
• Raw JSON block support, useful for advanced block types the node's visual editor doesn't cover.
• File downloads for files attached to database pages, directly from the node, without a separate HTTP Request call.
• A reorderable block builder, which simplifies composing complex pages with several nested block types.
• The Notion Trigger can now watch a specific data source instead of an entire database — relevant if only one source of a multi-source database should trigger the workflow.

Migrating an existing workflow without breaking production

The migration comes down to a few ordered steps:

1. Identify the affected nodes. Search your workflows for every Notion node (action or trigger) and any Code node or expression referencing archived or the transcription block type.
2. Check whether your databases are multi-source. If all your Notion databases have only one source, the immediate risk is low; if one of them has switched to multi-source, the node needs to be reconfigured with the correct data source before the workflow breaks in production.
3. Update the node to v3 and explicitly reselect the Data Source resource rather than leaving the old database identifier in place — v3 doesn't automatically guess which source to use.
4. Test in a development environment before deploying, following the same principle detailed in our guide on separating dev/prod environments in n8n: a modified Notion workflow deserves a full test run before it replaces the production version.
5. Version the change, so you can roll back quickly if an edge case was missed — see our guide on backing up and versioning n8n workflows with Git.

Where it matters most: RAG and editorial publishing

Two families of Notion workflows are particularly exposed. First, syncing a Notion knowledge base into a vector store for a RAG assistant — described in our RAG with Notion guide — where a documentation database that switched to multi-source can silently drop entire pages from the index if the node keeps querying the old default source. Second, an editorial calendar driven from Notion, like the one covered in our article on content planning with Notion and social media, where a page that no longer surfaces in the trigger simply goes unnoticed until a publishing deadline is missed. If your starting point is still the initial Notion-to-n8n connection, our Notion connection guide covers authentication and the base operations that this migration guide builds on.

This isn't an isolated case — why testing before deploying matters

This kind of breakage is nothing unusual in the world of third-party APIs. A study by Xavier, Brito, Hora and Valente, presented in 2017 at the SANER conference ("Historical and impact analysis of API breaking changes: a large-scale study", see on Google Scholar), analyzed more than 9,000 releases across 317 real-world Java libraries and nearly 260,000 client projects: close to 28% of the observed API changes broke backward compatibility, most often driven by new features or API simplification rather than an arbitrary choice. Notion's case fits that same pattern — a necessary evolution to enable multi-source databases, at the cost of a break for integrations that relied on the old structure. The practical takeaway holds regardless of which API is involved: never assume a third-party integration will stay frozen forever, and always test in a development environment before updating any node that touches an external data source.

Common pitfalls

• Forgetting the Notion Trigger: teams remember to migrate action nodes but the trigger relies on the same database identifier and breaks just as silently.
• Not sharing the new data source with the integration: just like the classic internal integration, each data source must be explicitly connected in Notion, or the API returns an empty list even after a successful node migration.
• Still filtering on archived in a Code node: the rename to in_trash doesn't raise an error — the condition simply becomes always false, a silent bug that's the hardest to spot without an explicit test.
• Migrating a production workflow without a test database: a duplicated Notion database for testing avoids discovering an edge case directly on real data.

Going further

This migration particularly affects document-syncing workflows — exactly the kind of building block shipped in the RAG Assistant Pack (€119), whose Notion-to-vector-store sync workflow directly benefits from v3's new markdown operations. If your document pipeline combines several sources (Notion, Google Drive, SharePoint), the FlowKit Complete Bundle (€269 instead of €347 bought separately) brings all the packs together to cover the full chain, from ingestion to compliance alerting.