Flowise memory for multiple users: sessionId per conversation, plus memory that follows the user across chats

Disclosure: I work on MemorySync (I'm Mohammed, the founder). I drafted this article with AI assistance and checked it against the official Flowise docs and the MemorySync docs. Code status: on Oct 30, 2026 I installed Flowise 3.1.4 and flowise-memorysync 1.1.0 from npm on a Linux box (Node 24.22.1), ran the node install commands from Step 6, and ran the Step 3 and Step 4 requests against a test chatflow (Buffer Memory + Conversation Chain). The chat model in that test was a local mock endpoint, not a real LLM, so no model key was used. Not run: the MemorySync node with a real MemorySync API key (no MemorySync request was made), the Step 7 payload with vars, and the embedded chat.

The MemorySync Flowise guide covers installing the MemorySync Memory node. This article starts one step earlier, with the question in FlowiseAI/Flowise discussion #1020: "I'm using it through API communication and I don't know how to differentiate one user from another." The person asking saw memory from earlier requests leaking into the next one, and wanted a way to give each user and conversation its own ID.

Flowise has an answer for that, and it's short: send a sessionId. But a sessionId only separates conversations. If you also want a user's facts to follow them into their next chat, that's a second, different job. This walkthrough does both.

A note on versions first. The FlowiseAI/Flowise GitHub repo is archived (the GitHub API showed archived: true on Oct 29, 2026, with the last push on Aug 13, 2026), and the MemorySync guide says Flowise's managed cloud was sunset in August 2026. Self-managed Flowise keeps running, so everything here assumes a self-managed instance. Flowise behaviour comes from the Flowise memory docs, the Prediction docs and the Variables docs.

Skip the memory plumbing around this setup. Once the steps below are in place, the MemorySync Flowise guide shows how to add per-user memory with MemorySync. MemorySync doesn't replace the per-conversation session setup. When you're ready, see MemorySync. Founding offer: use code FOUNDING30 for 30% off Starter for your first 3 months (Settings → Billing).

Step 1: Know when Flowise separates users for you

Per the Flowise memory docs, the built-in UI and the embedded chat already separate users. Flowise generates a unique chatId for each new interaction, so two people using the embed don't share a conversation.

The Prediction API is different. If you call POST /api/v1/prediction/{your-chatflowid} from your own backend and send nothing but question, Flowise has no way to tell your users apart. That's the situation in #1020.

Step 2: Allow overrides on the chatflow

You're going to send the session ID inside overrideConfig. Per the Prediction docs, override config is disabled by default for security reasons. Turn it on for the chatflow from the top right: Settings → Configuration → Security tab.

Turn it on anyway, because it's what the docs require for overrides and it's needed for variables in Step 7. One thing I saw on Flowise 3.1.4: overrideConfig.sessionId still separated Buffer Memory sessions on a test chatflow with override config left off. Flowise reads the memory session ID from the request separately from the node-input overrides. Don't rely on that; it isn't documented.

Step 3: Send a sessionId per conversation

Every Flowise memory node has a Session ID input. The docs' way to fill it from the API is overrideConfig.sessionId:

curl -X POST "http://localhost:3000/api/v1/prediction/<chatflow-id>" \
  -H "Content-Type: application/json" \
  -d '{
    "question": "hello!",
    "overrideConfig": { "sessionId": "user1" }
  }'

The same thing from Python, as a small helper your backend calls on every message:

import requests

FLOWISE = "http://localhost:3000"
CHATFLOW_ID = "<chatflow-id>"

def ask(question: str, session_id: str) -> dict:
    payload = {"question": question, "overrideConfig": {"sessionId": session_id}}
    r = requests.post(f"{FLOWISE}/api/v1/prediction/{CHATFLOW_ID}", json=payload, timeout=30)
    r.raise_for_status()
    return r.json()

How I'd pick the value (my suggestion, not a Flowise rule):

• Build it on your server from your own auth, for example f"{user_id}:{conversation_id}". Don't take it from the browser, or one user can type in another user's session.
• Keep it stable for the whole conversation. A new value is a new, empty conversation.
• Use a new value for a new conversation. One value per user forever means one ever-growing chat.

What this looked like on a real run (Flowise 3.1.4, Buffer Memory, a mock model that echoed back the user turns it received):

• Two requests with "sessionId": "alice": the second request's model call included both of alice's messages.
• One request with "sessionId": "bob": the model saw only bob's message, nothing from alice.
• A third alice request: the model saw all three alice messages and none of bob's.
• Two requests with no sessionId: each got a new random session ID in the response, so the second request didn't remember the first.
• A top-level "sessionId" outside overrideConfig was ignored (each call got a new random ID). A top-level chatId did group messages, but overrideConfig.sessionId is the documented field.

The response JSON echoes sessionId and chatId, which is a quick way to confirm which session a request landed in.

Step 4: Check what each session stored

The memory docs list a Message API for exactly this check. On Flowise 3.1.4 this endpoint needs authentication (an unauthenticated call returned Unauthorized Access), so call it with your Flowise API key or from a logged-in session:

# Messages for one session
curl "http://localhost:3000/api/v1/chatmessage/<chatflow-id>?sessionId=user1" \
  -H "Authorization: Bearer <FLOWISE_API_KEY>"

DELETE /api/v1/chatmessage/<chatflow-id> with the same sessionId query parameter removes that session's messages. Per the docs, you can also see and manage all conversations from the Flowise UI. If two users' messages show up under one sessionId, the bug is in how your backend builds the ID, not in the memory node.

Step 5: Decide whether you need memory across chats

Steps 1 to 4 fix the leak in #1020. They don't give you long-term memory. With one sessionId per conversation, a user who starts a new chat starts from zero, because that's what a new session means.

If you want a user's preferences and facts to come back in every chat, you need a second scope that belongs to the user, not the conversation. That's what the rest of this article sets up, with MemorySync (which I build) as the example.

Step 6: Add a memory node with separate user and session scopes (MemorySync example)

Per the MemorySync Flowise guide, you need self-managed Flowise 3.0+ on Node 18.15+ (community forks work too) and a MemorySync API key from the dashboard. Note that the flowise 3.1.4 npm package itself declares Node ^24 in its engines field, so check your Flowise version's requirement too. Flowise loads nodes from one directory, so the install is a package plus two copies:

npm install flowise-memorysync
cp -r node_modules/flowise-memorysync/dist/nodes/MemorySyncMemory <flowise>/node_modules/flowise-components/dist/nodes/
cp node_modules/flowise-memorysync/dist/credentials/MemorySyncApi.credential.js <flowise>/node_modules/flowise-components/dist/credentials/
# then restart Flowise

After the restart, MemorySync Memory appears under the Memory category and MemorySync API appears in the credentials list. Attach the node to a Conversation Chain or Agent like any built-in memory node, then set:

• Credential: MemorySync API.
• User ID: {{$vars.userId}}. The guide makes this field required, because without it every end user would share one memory.
• Session ID: leave it empty. Per the guide, each chat then gets its own transcript, while recall still covers all of the user's memories.

Step 7: Pass the user ID from your backend

{{$vars.userId}} is a Flowise variable. Per the Variables docs, you create the variable first (Static is fine, the API will override it), and setting a variable through the API also needs the override switch from Step 2. Then send it in overrideConfig.vars:

def ask(question: str, user_id: str, conversation_id: str) -> dict:
    payload = {
        "question": question,
        "overrideConfig": {
            "sessionId": f"{user_id}:{conversation_id}",
            "vars": {"userId": user_id},
        },
    }
    r = requests.post(f"{FLOWISE}/api/v1/prediction/{CHATFLOW_ID}", json=payload, timeout=30)
    r.raise_for_status()
    return r.json()

As in Step 3, user_id should come from your own auth on the server.

Step 8: Know what gets stored and what "clear" does

Per the MemorySync Flowise guide:

Recall arrives as one labelled SystemMessage block, and the guide lists topK (default 5) for how many memories come back. Deleting a user's long-term memories is a dashboard or API action, not something a chat clear does.

Skip the plumbing with MemorySync

Disclosure: I build MemorySync.

This doesn't change the fix above; it's the memory layer around it. From the guide:

npm install flowise-memorysync
cp -r node_modules/flowise-memorysync/dist/nodes/MemorySyncMemory  <flowise>/node_modules/flowise-components/dist/nodes/
cp    node_modules/flowise-memorysync/dist/credentials/MemorySyncApi.credential.js  <flowise>/node_modules/flowise-components/dist/credentials/
# restart Flowise

Snippet adapted from the MemorySync Flowise guide; I ran these three commands against Flowise 3.1.4 installed from npm; after a restart, MemorySync Memory showed up under Memory and MemorySync API in the credentials list. I didn't connect a MemorySync key or send a MemorySync request.

Try it: MemorySync is optional here: the steps above work without it. If you want the memory layer from the snippet, see MemorySync, create an API key in the dashboard and attach the MemorySync Memory node to your chatflow as in Step 6.

Troubleshooting

• Users still see each other's messages over the API. Check that override config is enabled on that chatflow (Step 2), and that every request carries a sessionId. Then list the session with the Message API (Step 4).
• Every message starts a new conversation. Your backend is generating a new sessionId per request. Keep it for the whole conversation.
• {{$vars.userId}} is empty or ignored. The variable has to exist in Flowise before the API can override it, and variable overrides need the Security-tab switch too (Variables docs).
• The MemorySync node isn't in the palette. Per the guide, the copy landed outside node_modules/flowise-components/dist/nodes, or Flowise wasn't restarted. There's no custom-nodes environment variable.
• The node disappeared after a Flowise upgrade. Upgrades replace node_modules. Run the two copy commands again.
• Saving the node fails on userId. It's required on purpose. Wire it to {{$vars.userId}}.

Common questions

How do I separate Flowise memory for multiple users through the API? Send a unique sessionId in overrideConfig on each POST /api/v1/prediction/{chatflowid} call, after enabling override config in the chatflow's Security settings (Flowise memory docs).

Does the embedded chat need a sessionId? No. Per the same docs, the UI and the embedded chat generate a unique chatId for each new interaction and keep users apart on their own.

Does a sessionId give a user memory across chats? No. It scopes one conversation. For facts that follow a user into new chats you need memory keyed by the user, such as a node with a separate User ID like the one in Step 6.

Is Flowise still maintained? The FlowiseAI/Flowise repository is archived on GitHub, and the MemorySync guide says the managed cloud was sunset in August 2026. Self-managed instances and community forks keep working.

Sources

• FlowiseAI/Flowise discussion #1020, "SessionId or ChatId for multiple users" (opened 2023-10-09)
• GitHub API for FlowiseAI/Flowise (archived: true, last push 2026-08-13), checked 2026-10-29
• Flowise docs: docs.flowiseai.com/integrations/langchain/memory, /using-flowise/prediction, /using-flowise/variables (fetched 2026-10-29)
• MemorySync Flowise guide: docs.memorysync.io/guides/flowise (fetched 2026-10-29)

Try it

For an overview of MemorySync, see the MemorySync homepage.

Next step: read the MemorySync Flowise guide, then see MemorySync. Founding offer: use code FOUNDING30 for 30% off Starter for your first 3 months (Settings → Billing).