How to Connect Notion to n8n and Build Your First Flow
How-to — — by Mahmoud Zalt
Create a Notion integration, paste the secret into n8n, then share each page with it. The step almost everyone misses is that last one.
Almost every person who reports that their n8n Notion node cannot find a database has done the first four steps correctly and skipped the fifth. The credential tests green, the node lists nothing, and an hour disappears into checking the token.
So read the sharing section below before you start, not after. Everything else here is genuinely straightforward, and the whole setup takes about five minutes once you know that the sharing step exists.
This guide covers the token route, which is what most people want, and explains when the OAuth route is the better choice instead.
How do I connect Notion to n8n?
You create an internal integration in Notion, enable its content capabilities, copy the token it generates, and use that as the internal integration secret on an n8n Notion credential. n8n's own documentation names each screen, and the capabilities you want are reading, updating and inserting content.
An internal integration is tied to one workspace, which is exactly right when you are automating your own Notion. Nothing about it is published or visible to anyone outside.
Connect Notion to n8n with a token
- Create the integration — Go to Notion's my integrations page and choose New integration. Give it a name you will recognise later, such as n8n integration, then submit it.
- Turn on the capabilities — Open the Capabilities tab and enable read content, update content and insert content, plus user information without email addresses if you need to read who did what. Save changes.
- Copy the token — Open the Secrets tab and copy the internal integration token. Treat this like a password, because that is what it is.
- Create the credential in n8n — Add a Notion node, create a new credential, and paste the token into the internal integration secret field. n8n tests the connection for you.
- Share the pages with your integration — This is the step everyone misses. Open each page or database, use the menu at the top right, find Connections, and connect your integration to it. Until you do, n8n sees nothing.
Why can n8n not see my database?
Because the page has not been shared with the integration yet. n8n's documentation states it plainly: for your integration to interact with Notion, you must give it permission on the pages you want it to reach. A valid token grants access to nothing on its own.
This is a deliberate design choice by Notion rather than an oversight. It means a leaked token is worth far less than it would be otherwise, because it only opens the pages somebody explicitly connected it to.
One useful shortcut: sharing a parent page shares what sits under it, so connecting your integration to the top of a section saves you doing it twenty times. Sharing a single database that lives elsewhere still needs its own connection.
If a workflow that worked last month suddenly returns nothing, check this first. A page that got moved out from under a shared parent quietly loses the connection, and the error you get back will not say so.
Should I use a token or OAuth?
Use the token for your own workspace, which covers almost everyone. Use OAuth when the workflow has to reach a Notion workspace you do not own, for example when you are building something your clients will connect to themselves.
| Question | Internal token | OAuth |
|---|---|---|
| Who it is for | Automating your own workspace | Reaching workspaces you do not own |
| Setup effort | Copy one secret | Public distribution, redirect address, client ID and secret |
| What you paste into n8n | The internal integration secret | A client ID and a client secret |
| Who grants page access | You, page by page | Each workspace owner, during their own sign in |
| Notion integration type | Internal | Public |
| Best default | Yes for most people | Only when you genuinely need it |
What can the Notion node actually do?
More than most people expect, and it is organised by the kind of thing you are touching. n8n's documentation groups the operations into blocks, data sources, databases, database pages, pages and users, each with its own small set of actions.
- Database pages: create, get, get many and update. This is the group you will use most, because a row in a Notion database is a page.
- Pages: archive, create, search, and get or update the page content as markdown. Note archive rather than delete, which matters more than it sounds.
- Blocks: append after, get many, and get as markdown. This is how you add content to the body of an existing page.
- Databases and data sources: get and search, for finding the thing you want to write into before you write into it.
- Users: get and get many, useful when a workflow needs to know who a person property points at.
For triggers, n8n documents two events: a page added to a database, and a page updated in a database. Between those two you can start a workflow from most of the things that happen in a Notion database day to day.
Building the flow is the easy part. Owning it forever is the expensive part, which is the observation that led to what we build at Sistava. You hire an AI Employee, connect Notion and whatever else it needs, and describe the outcome you want rather than drawing every node and branch by hand.
What this setup will not do
These are the edges you will meet eventually, and all of them come from the Notion API rather than from n8n. Knowing them now saves you designing a workflow that cannot work.
- It cannot reach a page nobody connected the integration to, no matter how correct the token is. Access is granted per page and inherited downward, never workspace wide by default.
- It cannot move data as fast as you would like. Notion documents an average of three requests per second per connection, and going over returns a rate limited error with a 429 response.
- It cannot post unlimited content in one go. Notion caps a request at a thousand block elements and around 500KB, with arrays of blocks or rich text limited to a hundred elements at a time.
- It cannot hold long text in a single rich text value. Notion documents a two thousand character limit there, so long summaries need splitting across blocks.
- It does not really delete. The node offers archive for pages, which is Notion's own model, so a workflow that promises a hard delete is promising something the API does not offer.
The rate limit is the one that bites in production. A workflow that loops over five hundred rows and updates each one will spend most of its life waiting, and the failure looks like a random error rather than a queue. Batch the work and add a wait if you hit it.
Frequently asked questions
FAQ
My credential says the connection tested successfully, so why is the database list empty?
Because the credential and the page access are two separate things. The test only proves the token is valid, not that the integration can reach anything. Open the database in Notion, use the menu at the top right, find Connections, and connect your integration. The list in n8n populates once at least one page or database has been shared.
Do I need to share every single page?
No. Access is inherited downward, so connecting the integration to a parent page covers what lives beneath it. What you do need to watch is pages that sit outside that tree, and pages that get moved later, since a page dragged out from under a shared parent quietly stops being reachable.
Which capabilities should I enable in Notion?
n8n's documentation lists read content, update content, insert content, and user information without email addresses. Enable only what your workflows actually need. If everything you build is read only reporting, leaving update and insert switched off is a cheap way to make an accidental overwrite impossible.
Why do I get a rate limited error on big runs?
Notion documents an average of three requests per second per connection, and requests beyond that return a rate limited error with a 429 response. A loop over hundreds of rows will hit it. The usual fixes are batching the items, adding a small wait between iterations, or restructuring so you make one query rather than one query per row.
Can n8n delete a Notion page?
The node offers archive rather than delete, which reflects how Notion itself works. Archiving takes the page out of the way and it can be restored. If your process genuinely requires content to be destroyed rather than filed, that is a decision to make inside Notion by a person, not something to automate through the API.
Is the Notion trigger reliable enough to build on?
It supports two events, a page added to a database and a page updated in a database, and n8n's own integrations listing labels the trigger as beta at the time of writing. Treat that label seriously for anything where a missed event would matter, and consider a scheduled check that reconciles state as a safety net rather than relying on the trigger alone.
Sources
- n8n Docs, Notion credentials for the integration setup, the capability names, the OAuth route and the page sharing requirement.
- n8n Docs, Notion node for the operations available on blocks, pages, database pages, databases and users.
- n8n Docs, Notion Trigger node for the two supported trigger events.
- Notion Docs, Request limits for the three requests per second average, the rate limited error and the payload size caps.
- Notion Docs, Create a Notion integration for the integration model itself.
Create the integration, copy the secret, then go and share the pages. Those three steps in that order will get you a working connection on the first attempt instead of the third. After that, the real work is deciding what the workflow should do and keeping it alive when a page moves or a property gets renamed. That maintenance is the part nobody budgets for, and it is exactly the part you can hand to somebody else. Have a look at Sistava if that sounds like the better trade.