# 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](https://docs.memorysync.io/guides/flowise?utm_source=hashnode&utm_medium=organic_page&utm_campaign=v5_oct25&utm_content=pseo_flowise-per-user-memory-sessionid) covers installing the MemorySync Memory node. This article starts one step earlier, with the question in [FlowiseAI/Flowise discussion #1020](https://github.com/FlowiseAI/Flowise/discussions/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](https://docs.flowiseai.com/integrations/langchain/memory), the [Prediction docs](https://docs.flowiseai.com/using-flowise/prediction) and the [Variables docs](https://docs.flowiseai.com/using-flowise/variables). > **Skip the memory plumbing around this setup.** Once the steps below are in place, the [MemorySync Flowise guide](https://docs.memorysync.io/guides/flowise?utm_source=hashnode&utm_medium=organic_page&utm_campaign=v5_oct25&utm_content=pseo_flowise-per-user-memory-sessionid) shows how to add per-user memory with MemorySync. MemorySync doesn't replace the per-conversation session setup. When you're ready, [see MemorySync](https://memorysync.io/?utm_source=hashnode&utm_medium=organic_page&utm_campaign=v5_oct25&utm_content=pseo_flowise-per-user-memory-sessionid). 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](https://docs.flowiseai.com/integrations/langchain/memory), 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](https://docs.flowiseai.com/using-flowise/prediction), 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`: ```bash curl -X POST "http://localhost:3000/api/v1/prediction/" \ -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: ```python import requests FLOWISE = "http://localhost:3000" 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: ```bash # Messages for one session curl "http://localhost:3000/api/v1/chatmessage/?sessionId=user1" \ -H "Authorization: Bearer " ``` `DELETE /api/v1/chatmessage/` 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](https://docs.memorysync.io/guides/flowise?utm_source=hashnode&utm_medium=organic_page&utm_campaign=v5_oct25&utm_content=pseo_flowise-per-user-memory-sessionid), 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: ```bash npm install flowise-memorysync cp -r node_modules/flowise-memorysync/dist/nodes/MemorySyncMemory /node_modules/flowise-components/dist/nodes/ cp node_modules/flowise-memorysync/dist/credentials/MemorySyncApi.credential.js /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](https://docs.flowiseai.com/using-flowise/variables), 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`: ```python 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](https://docs.memorysync.io/guides/flowise?utm_source=hashnode&utm_medium=organic_page&utm_campaign=v5_oct25&utm_content=pseo_flowise-per-user-memory-sessionid): | What | Where it goes | |---|---| | Each chat's messages (user and assistant) | Kept as that session's transcript and replayed into the flow, up to the History Window setting (default 10 turns). Not part of the user's memories | | The user's messages | Also sent for fact extraction. Durable facts become memories of the User ID and are recalled in every chat | | The assistant's replies | Stay in the transcript only | | "Clear this chat" | Removes that session's transcript and the facts extracted from it. Other chats and the user's other memories are untouched | 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: ```bash npm install flowise-memorysync cp -r node_modules/flowise-memorysync/dist/nodes/MemorySyncMemory /node_modules/flowise-components/dist/nodes/ cp node_modules/flowise-memorysync/dist/credentials/MemorySyncApi.credential.js /node_modules/flowise-components/dist/credentials/ # restart Flowise ``` *Snippet adapted from the [MemorySync Flowise guide](https://docs.memorysync.io/guides/flowise?utm_source=hashnode&utm_medium=organic_page&utm_campaign=v5_oct25&utm_content=pseo_flowise-per-user-memory-sessionid); 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](https://memorysync.io/?utm_source=hashnode&utm_medium=organic_page&utm_campaign=v5_oct25&utm_content=pseo_flowise-per-user-memory-sessionid), 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](https://docs.flowiseai.com/using-flowise/variables)). - **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](https://docs.flowiseai.com/integrations/langchain/memory)). **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](https://memorysync.io/?utm_source=hashnode&utm_medium=organic_page&utm_campaign=v5_oct25&utm_content=pseo_flowise-per-user-memory-sessionid). **Next step:** read the [MemorySync Flowise guide](https://docs.memorysync.io/guides/flowise?utm_source=hashnode&utm_medium=organic_page&utm_campaign=v5_oct25&utm_content=pseo_flowise-per-user-memory-sessionid), then [see MemorySync](https://memorysync.io/?utm_source=hashnode&utm_medium=organic_page&utm_campaign=v5_oct25&utm_content=pseo_flowise-per-user-memory-sessionid). Founding offer: use code FOUNDING30 for 30% off Starter for your first 3 months (Settings → Billing).