FlowKit

Connecting Notion to n8n: syncing a database and automating your pages (complete guide)

Published 23 July 2026 · 6 min read

Notion serves as the knowledge base for most teams that don't have a real database: product documentation, internal procedures, a prospect list, a team wiki. The problem is that this content stays locked inside the Notion interface unless something automatically goes and fetches it. Connecting Notion to n8n changes that dynamic: a new row in a database can trigger a workflow, and conversely n8n can write, update or vectorize Notion pages without manual intervention. This guide covers authentication, the Notion node's operations, the trigger, property pitfalls, and two concrete examples — including syncing to a vector store for a RAG assistant.

This friction isn't unique to Notion: a landmark information systems review by Maryam Alavi and Dorothy Leidner, published in 2001 in MIS Quarterly, already described the core problem of knowledge management systems — the difficulty of moving stored information toward the processes that actually need it, rather than leaving it dormant in a repository consulted only on demand (Alavi & Leidner, 2001, MIS Quarterly). An n8n pipeline that automatically pushes and pulls Notion content to a team's other tools (Slack, a vector store, a CRM) is a fairly direct answer to that problem, twenty-five years later.

When Notion makes sense as a source for n8n

Three use cases come up most often:

  • AI-searchable knowledge base: procedures, product documentation or meeting notes stored in Notion get vectorized by n8n and become the source for a RAG chatbot that answers with citations, instead of staying pages that have to be searched manually.
  • Lightweight project or editorial tracking: a Notion database (statuses, dates, assignees) as a dashboard a non-technical team can edit, while n8n triggers notifications or actions on a status change.
  • Configuration back-office: exactly like Airtable, a Notion database can serve as a workflow's configuration panel — a list of feeds to watch, feature flags, a contact list — editable without touching the workflow's JSON.

If volume grows past several thousand rows with complex queries, or data freshness needs to be measured in seconds rather than minutes, Notion shows its limits earlier than a real Postgres instance would — our n8n-Supabase connection guide covers the alternative once that threshold is reached.

Authentication: the internal integration

The recommended method for a backend use case in n8n is a Notion internal integration, created at notion.so/my-integrations:

  1. Click "New integration," give it an explicit name ("n8n — production sync" rather than "Test"), and associate it with your workspace.
  2. Copy the displayed Internal Integration Secret — this is the only time it's shown in clear text.
  3. In n8n: Credentials → New → Notion API, paste the secret. No OAuth2 flow to manage for this use case.

Notion also offers OAuth2 credentials on the n8n side, useful when multiple users each need to authenticate with their own account — but only the internal integration (API Access Token) supports the Notion Trigger node: if your workflow needs to fire on a change, go straight for the internal integration.

The step everyone forgets: an integration sees no pages by default. You need to open each relevant page or database in Notion, click the three dots in the top right → Connections → add the integration. Without this explicit sharing step, the API returns an empty list even with a perfectly valid token — the most common source of confusion when starting an integration.

The Notion node's operations

The Notion node covers two main resources, each with its own operations:

Database resource:

  • Get All / Get Many: lists a database's pages, with a filter and sort system that mirrors Notion's native filters (by property, by condition).
  • Search: searches databases accessible to the integration by keyword.

Page resource (the equivalent of a row in a database, or a standalone page):

  • Create: creates a page inside a database, mapping each property (title, select, date, relation…) onto the schema Notion expects.
  • Update: modifies an existing page's properties based on its pageId.
  • Get / Get All Blocks: retrieve, respectively, a page's properties and the actual text content of its body — two distinct things people often conflate. Properties give you the status or the date; blocks give you what's actually written on the page.
  • Archive: archives a page (Notion's equivalent of a reversible delete).

One thing to watch on Create and Update: each property must be sent in the exact format its Notion type expects (a select expects { name: "Value" }, a date expects a { start: "2026-07-23" } object). The n8n node simplifies this mapping, but a property added later on the Notion side (a new status added to a select) only shows up after a schema refresh — click the refresh icon on the field if a recent value is missing from the dropdown.

The Notion trigger: polling, not a webhook

n8n's Notion Trigger periodically queries a watched database and compares each page's last-modified timestamp since its previous run, so the workflow only fires on new or changed pages. Two things to know:

  • It is not a real-time push event: the Notion API doesn't expose a native webhook for this use case on the n8n side — expect a delay equal to the configured polling interval (one minute at minimum in practice) before a change triggers the workflow.
  • Only the internal integration works: as mentioned above, an OAuth2 credential can't be used with this trigger — n8n will refuse to configure it with that credential type.

For finer-grained reactivity (detecting a specific status change rather than "the page changed"), one option is to run the trigger on a short interval and filter afterward with an IF node on the property you actually care about, instead of treating every modification as equivalent.

Rate limit: 3 requests per second

The Notion API caps each internal integration at an average of 3 requests per second, with short bursts tolerated beyond that threshold. Exceeding it returns a 429 status with a Retry-After header indicating the recommended wait time. On an n8n workflow looping over a large number of pages (a full sync, for example), add a short Wait node between calls or batch with Split In Batches — the same quota-respecting logic described in our article on pagination with the HTTP Request node.

Concrete example #1: Notion database → Slack notification

A representative pipeline for task or editorial content tracking:

  1. Notion Trigger watches an "Articles" database and fires on any modified page.
  2. An IF node filters on the Status = "Ready to publish" property, ignoring other changes (in review, draft).
  3. A Slack node notifies the editorial team with the title, assigned author and a direct link to the Notion page (https://notion.so/{pageId}), for immediate action without switching tools.

Concrete example #2: syncing Notion to a vector store for RAG

This is the most common use case for teams that already document their procedures in Notion and want an assistant that can answer from them:

  1. Notion Trigger (or a daily Schedule trigger, which is more request-efficient than frequent polling) detects new or modified pages in a documentation database.
  2. The Notion node fetches the full content via Get All Blocks, then a Code node flattens Notion's block structure (paragraphs, lists, headings) into plain usable text.
  3. The text is chunked and turned into embeddings, then inserted into Supabase pgvector with the Upsert operation — keyed on the Notion page ID, so updating an existing page replaces its embedding instead of creating a duplicate. The details of this vectorization mechanism are covered in our Supabase pgvector guide.
  4. A RAG chatbot can then answer team questions while citing the source Notion page — exactly the pipeline packaged as the sync-notion-base-vectorielle workflow in the RAG Assistant Pack.

Summary

The internal integration with its API secret is the authentication method to favor — it's the only one that supports the trigger, and you must remember to explicitly share each page or database with the integration from the Notion interface. The trigger remains polling-based, the 3-requests-per-second limit is handled with a delay or batching, and the distinction between a page's properties and its block content is the most common pitfall when starting an integration. To go beyond a simple sync and wire Notion directly into a full documentary assistant (PDF ingestion, citation-backed chatbot, API endpoint), the RAG Assistant Pack (€119) ships the four workflows already assembled, including this Notion-to-pgvector sync ready to import.

FAQ

Frequently asked questions

Should I use OAuth2 or the internal integration to connect Notion to n8n?

For a backend use case in n8n, the internal integration (with its API secret) is the right choice: it is simpler to set up and it is the only method that supports the Notion Trigger node. OAuth2 credentials exist on the n8n side but do not work with the trigger — reserve them for a scenario where multiple users each need to authenticate with their own Notion account.

Why doesn't my Notion integration see any pages in n8n?

An internal integration only sees pages and databases explicitly shared with it. Open the relevant page or database in Notion, click the three dots in the top right, "Connections," then add your integration. Without this step, the API returns an empty list even with a valid token.

Is n8n's Notion trigger a real webhook?

No, it is polling: n8n periodically queries the watched database and compares each page's last-modified timestamp since its previous run. The Notion API does not expose a native push event for this use case — expect a delay equal to the configured polling interval before a change triggers the workflow.

What Notion API rate limit should I know about in n8n?

The Notion API caps an internal integration at an average of 3 requests per second, with short bursts tolerated beyond that. Exceeding it returns a 429 status with a Retry-After header. On a workflow looping over many pages, add a small delay between calls or batch with Split In Batches.

How do I fetch a Notion page's full text content, not just its properties?

A page's properties (title, status, tags) are different from its content (the body blocks). The Notion node needs the Get All Blocks operation (or a recursive query over child blocks) to retrieve the text actually written in the page — properties alone are not enough.

Bundle FlowKit Complet

€269