--- title: "Dify memory: conversation memory and dated recall" description: "Dify memory keeps chat history per conversation, and conversation variables last one chat session. Add timestamped recall with HTTP Request nodes or an MCP server." canonical: https://past.dev/integrations/dify last-updated: 2026-10-09 --- # Add memory to Dify apps Source: https://past.dev/integrations/dify Dify memory is scoped to one conversation. The LLM node's memory includes earlier turns of the current Chatflow conversation, an Agent app keeps its own memory per conversation, and conversation variables persist for one chat session. A new conversation starts fresh. Two HTTP Request nodes connect a Dify workflow to past.dev for timestamped ingestion and recall that returns ranked documents with dates and source excerpts. ## Dify memory scope The [LLM node](https://docs.dify.ai/en/cloud/use-dify/nodes/llm) can enable Memory to include previous interactions of a Chatflow conversation in its prompts. That memory belongs to the node and does not persist between conversations. In an [Agent app](https://docs.dify.ai/en/cloud/use-dify/build/new-agent/overview), each conversation has its own memory, bounded by the model's context window, and a new conversation starts fresh. [Conversation variables](https://docs.dify.ai/en/cloud/use-dify/nodes/variable-assigner) persist across the turns of one chat session. The Variable Assigner node writes them, and later turns read them. - **Memory ends with the conversation.** A returning user starts a new conversation with none of it. - **Conversation variables are application state.** They hold what the workflow writes, for one session. - **History is bounded.** The Agent node's memory window and the model's context window cap how much history the model receives. ## The integration: two HTTP Request nodes 1. **Recall.** Before the LLM or Agent node, add an HTTP Request node: POST to `https://api.past.dev/api/v1/recall`, authorization **API Key** of type **Bearer** with your project key, and a JSON body with `query` set to the user's message and `identity` set to `sys.user_id`. Reference the response body in the prompt as context. 2. **Remember.** Where the workflow confirms a durable fact, add an HTTP Request node: POST to `https://api.past.dev/api/v1/ingest` with a JSON body of `content`, `timestamp` and `identity` set to `sys.user_id`. The [HTTP Request node](https://docs.dify.ai/en/cloud/use-dify/nodes/http-request) inserts workflow variables with double curly braces, and its Bearer key type adds the `Authorization: Bearer` header. `sys.user_id` identifies each application user ([variables](https://docs.dify.ai/en/learn/key-concepts)). Through the API, it carries the `user` value that your application sends with each call, and Dify does not authenticate that value ([end user identity](https://docs.dify.ai/en/api-reference/guides/end-user-identity)). Call the Dify API from your server, with the signed-in user's id as `user`. > **Identity** > > The application sets the identity. The model never chooses it. Recall returns what the identity in the request may read, so take the identity from the signed-in user in code, and keep it out of every value that the model fills. Recall returns ranked documents with dates and source excerpts. The application decides whether those documents support an answer, contain a disagreement, or are insufficient; HTTP failures are handled separately. ## Or connect the MCP server Dify imports tools from MCP servers that use HTTP transport, on the **MCP** tab of **Integrations › Tools** ([Dify tools](https://docs.dify.ai/en/cloud/use-dify/workspace/tools)). MCP tools work in Agent apps, and in Workflow and Chatflow apps as Tool nodes or inside Agent nodes. The project's end-user MCP server then gives the agent `recall`, `answer` and `who_am_i`, plus `remember` while the project's write toggle is on, with no tool code to write. 1. Turn on the project's end-user MCP server on **Build › MCP server** in the console. 2. Mint an access link there, or with the account server's `create_mcp_access_link` tool. The link has the form `https://api.past.dev/mcp//link/`. It is one URL that is one identity, and the server answers it with no sign-in step. 3. Keep the link out of shared documents, tickets and chat. The secret in its path is the credential. Add the server with the access link as its URL, a name and a server identifier. The link carries its own credential, so the server needs no OAuth registration and no custom header. Every user of an app that calls the server acts as the link's identity. An app that serves several people reads memory through the HTTP Request nodes, which send each user's `sys.user_id`. Every call through the link runs as its identity, with that identity's audiences. Mint one link per install, so that a revoked link stops one agent only. When the agent serves several people, mint one link per end user, and connect each request with the link of the user who makes it. Never share one link between users. `remember` writes to the identity's own private audience, and only that identity recalls it. Send data that the whole project must recall through the ingest call. The [end-user server documentation](/docs/mcp/serving-your-own-users) describes the tools, the links and revocation. ## When to use which - Follow-up questions inside one conversation: LLM node memory or the Agent app's memory. - State the workflow tracks during one session: conversation variables. - Facts that must reach a returning user, another app or another workflow, with dates and source excerpts: the HTTP Request nodes or the MCP server above. The [quickstart](/docs/memory-api/quickstart) shows how to ingest, wait until ingestion completes, and recall. The [benchmarks](/benchmarks) document how recall is measured. [Session memory](/glossary/session-memory) defines the layer Dify provides. ## Frequently asked questions ### Does Dify remember users across conversations? Dify memory and conversation variables last one conversation, and a new conversation starts fresh. Memory across conversations needs a store that the workflow calls, such as a memory API. ### Do I need code to connect Dify to past.dev? No. Two HTTP Request nodes with a Bearer key cover recall and ingestion, and an access link adds the end-user MCP server as a tool provider. ## Related - [Memory for n8n](https://past.dev/integrations/n8n) - [Memory for Flowise](https://past.dev/integrations/flowise) - [Memory for CrewAI](https://past.dev/integrations/crewai) - [Session memory](https://past.dev/glossary/session-memory) - [Quickstart](https://past.dev/docs/memory-api/quickstart)