Resources · n8n integration

n8n MongoDB Chat Memory nodeConfigure MongoDB Chat Memory in n8n.

A chatbot that forgets everything between two messages is not a chatbot. The n8n MongoDB Chat Memory node is a sub-node, a helper node with no main input that plugs into the Memory port of a root node and writes each exchange into a MongoDB collection. Four parameters, one version.

Verified Trustpilot reviews · AI, automation & growth agency

Why automate

What does the n8n MongoDB Chat Memory node actually store?

It stores the chat history of a conversation in a MongoDB collection, so the model gets the previous turns back on the next message. In an AI context, memory is what lets a tool keep message context across interactions instead of receiving the whole conversation again in every prompt. The node itself never runs alone: it waits on the Memory port of a root node and answers when that node asks for history.

The first scenario is the one most people land here for: a support assistant that answers on a chat widget. The root node handles the question, and Collection Name points at the MongoDB collection where every question and answer pair ends up. The collection does not have to exist beforehand, n8n creates it on the first write. Plug the node into an AI Agent and the follow-up question keeps its subject.

Second scenario, a multi-tenant assistant. One MongoDB database, one collection, and one conversation per customer, kept apart by the session key. That key is the whole point of Session ID: two visitors who share a session key share a conversation, which is exactly what you do not want. The same separation applies when an agent is exposed as a tool through AI Agent Tool.

Third scenario, long conversations that get expensive. Context Window Length caps how many past interactions travel with each call, so a thread that has been running all afternoon does not replay itself to the model every time. The model provider, whether that is OpenAI, Google Gemini or another one, bills its own API calls under its own terms, and n8n adds nothing on top of that.

When would you skip this node? When the conversation does not need to survive the workflow run. Memory is available to AI agent nodes, not to AI chains, so a chain that classifies one message at a time has nothing to gain here. And if the workflow already runs on a MongoDB instance you would rather not open to chat logs, the node is not the right place to force it.

Two limits worth knowing before you build. Add a second MongoDB Chat Memory node to the same workflow and both point at the same memory instance by default, so a destructive action on one is a destructive action on the other. Set different session IDs when you want genuinely separate instances. Second limit, the page describes version 1 of the node, the highest one in the catalog, and an older workflow may show fewer options. More context on the platform itself sits in the n8n review.

Connect

What do you connect before the node works?

  1. 01

    Create the MongoDB credential

    Open the Credentials menu in n8n and create a MongoDB credential, the stored set of connection details n8n reuses instead of asking you again in every workflow. The official n8n documentation covers the authentication details for this node. Once saved, the same credential serves every workflow on the instance, on n8n Cloud as well as on a self-hosted install.

  2. 02

    Select it on the node

    Drop the node on the canvas and pick that credential in its credential selector. There is no Authentication dropdown to choose from here: the node has one credential type and nothing else to arbitrate. The node ships inside the n8n AI package, so nothing needs installing first, on n8n Cloud or on a self-hosted instance.

  3. 03

    Point it at a database and a collection

    Leave Database Name empty and the node uses the database carried by the credential itself. Fill it in when the chat history belongs somewhere else than the default. Then set Collection Name, and stop worrying about creating it by hand: if the collection does not exist, the node creates it.

Connections

Where does the node plug in?

n8n AI nodes work as a root node that receives the workflow items, with sub-nodes hanging off its ports, one type of sub-node per port. This one is a sub-node with a single output, so the only question is which root node it serves.

Output (what it plugs into)

  • Memoryai_memory
01MemoryThe Memory port is where a root node asks for past messages before calling the model, then writes the new exchange. This node occupies that port and nothing else.

The Memory port is where a root node asks for past messages before calling the model, then writes the new exchange. This node occupies that port and nothing else.

Key parameters

  • Optional: a root node runs without memory, it just answers each message as if it were the first.
  • AI Agent: the usual host, the agent that answers and needs the earlier turns.
  • AI Agent Tool: same idea when the agent is itself called as a tool by another one.
  • Chat Memory Manager: reads or rewrites the stored history on purpose.
  • Chat Trigger: the chat entry point holds the thread from the first message.
Use cases
an agent answering on a chat widget keeps the thread open across messages, and a Chat Memory Manager alongside it lets you inspect or clear that same history.
Parameters

How do you set the four parameters?

The MongoDB Chat Memory node has 4 parameters. For each one: the node as you configure it in n8n, what the parameter changes, and our field notes.

01

Session ID

sessionIdType

What you see in n8n

Notes & use cases

This decides how the node names the conversation it reads and writes. Get it wrong and two users share one thread.

Key parameters

  • Connected Chat Trigger Node (fromInput): looks for an input field called sessionId coming from a directly connected Chat Trigger.
  • Define below (customKey): use an expression to reference data in previous nodes, or enter static text.
  • Session Key From Previous Node: the field that appears with the second choice, typically {{ $json.sessionId }} or a customer identifier.
Use cases
a public chat widget takes the first option and forgets about it; an assistant fed by a form or a CRM record takes the second and keys the thread on the contact.
02

Collection Name

collectionName

What you see in n8n

Notes & use cases

Names the MongoDB collection where the chat history is stored. If the collection does not exist, it will be created, so there is no setup step in MongoDB before the first run.

Key parameters

  • Collection Name: the collection name to store the chat history in, a plain string such as chat_history, or an expression when one workflow serves several products.
Use cases
keeping support conversations in one collection and sales conversations in another makes later cleanup a one-line job instead of a filtered delete across a shared collection.
03

Database Name

databaseName

What you see in n8n

Notes & use cases

Chooses which MongoDB database holds that collection. Left empty, the database from credentials will be used, which is what you want as long as one credential serves one environment.

Key parameters

  • Database Name: the database name to store the chat history in, filled only when the history belongs outside the credential default.
Use cases
a staging workflow and a production workflow can share one credential and still write their histories apart, by naming the database here on the staging copy only.
04

Context Window Length

contextWindowLength

What you see in n8n

Notes & use cases

Sets how many past interactions the model receives as context. It is the dial between an assistant that remembers the whole thread and one that only remembers the last few turns.

Key parameters

  • Context Window Length: a number of previous interactions, raised when answers need the early part of the conversation, lowered when each call carries too much history.
Use cases
a booking assistant that only needs the last few turns to finish an order runs on a small value, while a technical troubleshooting thread usually needs more of its own history to stay coherent.
Need help

Need help automating MongoDB Chat Memory with n8n?

A person reads every message.

FAQ

MongoDB Chat Memory and n8n, the questions that come next

01Is the MongoDB Chat Memory node included in n8n?
Yes. It belongs to the n8n AI package and ships with n8n, so there is nothing to install and nothing extra to pay on the n8n side, on n8n Cloud as well as on a self-hosted instance running the Community Edition under the Sustainable Use licence. n8n can be self-hosted with Docker or npm, or used on n8n Cloud, the hosted offer run by n8n, and a workflow behaves the same either way. What can cost money is the model provider connected to the root node, since OpenAI, Anthropic, Google, Mistral and the others bill their own API calls under their own terms. n8n adds nothing on top of that.
02What credentials does the node need?
A MongoDB credential, created once in the Credentials menu of n8n and reused in every workflow on the instance. The node has no Authentication selector to pick from, so there is a single credential type and no arbitration to make. Authentication details for this node are covered in the official n8n documentation. That credential also carries a database, which matters for the parameters: leave Database Name empty and the node writes to the database from credentials, fill it in and the node writes wherever you named. Collection Name has no such fallback, and the collection is created on the first write if it does not exist yet.
03What are the limits of the n8n MongoDB Chat Memory node?
Three worth planning for. Add more than one MongoDB Chat Memory node to a workflow and all of them access the same memory instance by default, so a destructive action such as overriding all messages from a Chat Memory Manager hits every one of them. Setting different session IDs in the different memory nodes is how you get genuinely separate instances. Memory is available to AI agent nodes, not to AI chains, so a chain cannot use this node at all. And the four parameters described here belong to version 1 of the node, the highest in the catalog, so an older workflow may show fewer options.
04What do you need to plug in for the memory to work?
A root node, on its Memory port. This node is a sub-node: it has no main input and never runs on its own. The root nodes that accept it are the AI Agent, the AI Agent Tool, the Chat Memory Manager and the Chat Trigger. Memory is optional on those nodes, so a workflow runs fine without it and simply answers each message with no idea what came before. If you are starting out, wire an AI Agent to a chat entry point, connect this node to its Memory port, and take the Connected Chat Trigger Node option so the session key arrives on its own.
05n8n or Make for a chatbot with persistent memory?
It depends on where the data has to live. Make is a hosted automation platform with no self-hosting option and pricing per operation, so the chat history goes through infrastructure you do not run. n8n can be self-hosted with Docker or npm, which puts the workflow and the MongoDB connection on machines you control, or used on n8n Cloud when that is not a requirement. Cost models differ in the same way, one per operation, the other tied to how you host. On visual logic, both build the flow on a canvas; the n8n AI nodes add the root node and sub-node model, which is what makes a memory node a separate block on a port rather than a setting buried in a module.
Hack'celeration Lab

Get our weekly integration tips.

No spam. Unsubscribe anytime.