n8n's Native Confluence Node: Pulling an Entire Page Tree for RAG

Until now, connecting n8n to Confluence for a RAG pipeline meant going through the HTTP Request node and the Confluence Cloud REST API: manual API token handling, page-by-page pagination, and no way to pull a full page tree without hand-coding the recursion over children yourself. Our guide to RAG on Confluence documented exactly that approach, for lack of a native alternative. With n8n 2.40.0, released on September 15, 2026, that is no longer the case: a native Confluence node has shipped, with OAuth2 authentication managed by n8n and an option that concretely changes how you ingest a Confluence knowledge base for retrieval-augmented generation.

This is not a cosmetic detail. An architecture that preserves a corpus's hierarchical structure instead of flattening it into a list of fragments improves retrieval quality: that is exactly what Sarthi and co-authors (Stanford) show in RAPTOR: Recursive Abstractive Processing for Tree-Organized Retrieval (ICLR 2024), where indexing a tree of summaries at multiple levels of abstraction outperforms retrieving short, isolated fragments on tasks that require a holistic understanding of the document. A Confluence space is exactly a tree — a procedures folder with its sub-pages, a product knowledge base organized into chapters — and a node that returns it in outline order rather than scrambled makes the chunking work that follows much easier.

What changes with the native node

The native Confluence node exposes around fifteen operations across four resources: Page (create, read, update, delete, and list footer comments), Attachment, Search, and Space. For a RAG use case, the Page and Search resources matter most: Page for content extraction, Search for quickly locating relevant pages in a large space before indexing them.

The most visible difference from the old HTTP Request approach is authentication. No more generating an API token on a service account and storing it as Basic Auth: the node uses a Confluence Cloud OAuth2 credential, configured once. From the Atlassian Developer Console, you create an OAuth 2.0 integration, paste the redirect URL provided by n8n into the callback field, add the Confluence scopes needed for reading (and writing, if the workflow needs to create or update pages), then authorize the connection from n8n. The offline_access scope is requested automatically so the token can refresh without going back through the sign-in screen every time it expires. In the node itself, the Site parameter then lets you pick among the Confluence sites the connection can access, or paste the site URL directly if several organizations are involved.

Get Page + Include Descendants: a whole tree in one node

The real change for an ingestion pipeline sits in the Get operation of the Page resource, with the Include Descendants option turned on. Instead of returning only the requested page, the node recursively walks all of its descendants — sub-pages, sub-sub-pages, across the full depth of the tree — and returns them in a single output, with a configurable cap via Max Pages so a huge space cannot blow up an execution's memory.

This mechanism already existed, but with two defects only fixed in version 2.40.0. First, an ordering issue: pages came out sorted by the internal ID Confluence assigned when they were created, not by their position in the tree — a child could appear before its own parent in the stream, complicating the reconstruction of the document outline downstream. The fix now reorders pages according to the actual tree walk, with the root always leading. Second, a budget issue: draft (unpublished) pages consumed a slot of the Max Pages quota without ever showing up in the output, wasting part of the set limit on invisible content; the available budget now only counts pages actually published, while the node still walks below a draft to reach any published descendants.

In practice, a single Confluence node configured on a documentation space's root page, with Include Descendants enabled, replaces what used to require a Loop Over Items loop paired with recursive HTTP Request calls against the /child/page API.

Adapting an existing RAG pipeline

If you already built a pipeline following the HTTP Request approach described in our guide to RAG on Confluence, nothing forces a full rewrite: only the extraction step changes, not what comes after. The native node's output format is still content structured per page (title, body, _links metadata), so the steps for converting to text, chunking documents for RAG while respecting section headings, generating embeddings, and storing them in Supabase with pgvector — described in our RAG with Supabase guide — stay the same. One difference to plan for: the page body returned by the native node can differ slightly from the raw storage format used by the old HTTP approach, so testing on a handful of representative pages (with macros, tables, embedded attachments) before launching a full index run avoids unpleasant surprises.

For needs that go beyond simple tree extraction — a CQL query combining several spaces with filters on custom metadata, for instance — the direct HTTP Request node against the REST API still earns its keep: the native node simplifies the common case, it does not claim to cover every advanced use.

Best practices for ingestion

A few things worth watching in production:

• Size Max Pages deliberately. A space with several thousand pages can exceed a limit set too low; it is better to segment ingestion by sub-tree (one root page per team or product) than to pull an entire space in a single run.
• Respect the Confluence Cloud API's rate limits, as with any Atlassian connector — the same principle detailed in our article on RAG with Notion applies: sequence rather than parallelize, and enable retry on the relevant nodes.
• Plan for incremental sync rather than a full reindex on every run, filtering on the last-modified date and applying the same delete-then-insert pattern used for other document sources, detailed in our guide to keeping a RAG index up to date.
• Stick to a dedicated service account for the OAuth2 credential, with read-only access limited to the spaces you index.

If you would rather not assemble this pipeline piece by piece, the RAG Assistant Pack (€119) provides the downstream half ready to plug in — ingestion into Supabase pgvector, a chatbot with citations, and a question-answering API — for you to connect to the Confluence extraction, whether through the new native node or the older HTTP Request approach depending on your needs.

In summary

• n8n 2.40.0 (September 15, 2026) introduces a native Confluence node: an OAuth2 credential managed by n8n, with Page, Attachment, Search, and Space resources.
• The Include Descendants option on the Get Page operation fetches an entire tree in one node, in true tree order since this fix — a point that matters for the quality of a hierarchical RAG index.
• Draft pages no longer waste the Max Pages budget, while still being walked to reach their published descendants.
• OAuth2 authentication replaces the Basic Auth API token for simple cases; direct HTTP Request remains relevant for advanced CQL queries.
• The rest of the RAG pipeline (conversion, chunking, embeddings, storage, incremental sync) is unchanged.