Does Typebot Remember Between Sessions? What Persists and What Starts Blank

The short answer: Typebot has an excellent memory within a session, and almost none between sessions. Its engine tracks every block, variable, and answer while a conversation is live. The moment the session ends or expires, that working memory is gone unless you deliberately saved it somewhere durable. If you are running Typebot as part of an automation and you expect the bot to recognize a returning visitor or carry context from last week's conversation, you need to understand exactly where the line is drawn.

Here is the breakdown, based on Typebot's own documentation and source code.

What Typebot remembers while a session is live

Typebot's session management is thorough. Every conversation is backed by a ChatSession database record identified by a unique sessionId, and that session persists across multiple API calls. During an active session, Typebot tracks:

• The current position in the flow (currentBlockId)
• Every variable value, plus the history of how those values changed
• Every answer the visitor has submitted
• Rendering metadata: theme, progress, typing emulation
• Channel-specific data, like WhatsApp contact details

In other words, inside one conversation, the bot never loses its place. It knows what it asked, what the visitor answered, and what it should do next. This is the persistence the docs describe, and it works well for the happy path: one visitor, one uninterrupted chat, start to finish.

What survives past the session: the Results table, but only if you opt in

Here is the line most builders miss. Variables in Typebot exist, by default, only during the active chat session. To keep a value after the session ends, you have to turn on Save in results on the variable. Saved values land in Typebot's Results table, where you can review them later.

That is a deliberate design choice, and it is worth naming plainly: Typebot treats long-lived data as something you export to a table, not as something the bot carries in its head. The Results table gives you a ledger of what happened. It does not give the next session any awareness of it. A visitor who returns tomorrow starts a fresh session with empty variables, regardless of how much data the Results table holds about their previous visit.

If your automation depends on "the bot remembers that this person already gave their email," that continuity does not exist unless you rebuild it: prefill variables when starting the chat, or look the visitor up in an external store at the start of every session.

The OpenAI block: memory across messages, not across sessions

Typebot's OpenAI block has two memory-relevant features, and both are scoped to the conversation at hand.

First, the Dialogue message type lets you pass a sequence of saved assistant and user messages into a chat completion, so the model can see the conversation history you hand it.

Second, the Ask Model action uses the Responses API with multi-turn conversation support. To keep conversation history across messages, you assign a variable to the Response ID field. Typebot's docs are explicit about the mechanics: if the variable is empty, a new conversation is started; on each response, the variable is automatically updated so the next invocation continues the same conversation.

Read that carefully, because it is the crux of the whole topic. Typebot gives you the mechanism for AI conversation memory (the Response ID variable), but the persistence of that mechanism is exactly as durable as the variable holding it. Keep the Response ID in a session variable and the AI remembers the whole conversation, until the session expires. Save it somewhere durable and pass it back in on the next session, and the model can pick up where it left off. Lose it, and the model starts blank, no matter how much the last conversation covered.

There is no built-in "remember this visitor across sessions" behavior. There is a hook you can use to build it yourself.

What starts blank every session

Putting it together, here is what does not carry over:

• Variables, unless saved to the Results table or an external store
• AI conversation context, unless the Response ID is persisted and re-injected
• Corrections and preferences. If a visitor corrects the bot mid-chat ("no, my budget is 5k, not 10k"), that correction lives in the session's variables and dies with the session
• Cross-visitor learning. Nothing one conversation teaches the bot is automatically available to the next visitor's conversation

This is not a flaw in Typebot so much as a scope decision. Typebot is a flow engine: it remembers where it is, not who it is talking to over time. For a one-shot lead form or a guided troubleshooting flow, that is exactly right. For a support bot that should greet a returning customer with the context of last month's ticket, or a qualification bot that should not ask the same five questions twice, the built-in memory model runs out.

The pattern that actually fixes it: memory outside the platform

Every platform in this series hits the same wall: session-scoped memory with a handful of escape hatches that push the real continuity problem back onto you. The durable fix is the same everywhere, which is to stop asking the flow engine to be a memory system and give the memory to a layer that outlives every session by design.

That is what Vilix AI is: a hosted memory layer your automations read and write over MCP. Because it is cloud-hosted, there is zero infrastructure to run; you connect the tool once and the same memory follows the agent across Typebot, n8n, Claude Code, and every other tool in the stack, instead of living inside one platform's session table. It stores full conversation history, not just extracted facts, so the correction a visitor made three weeks ago is still retrievable when the next run needs it. There is a free plan that stays free, a 7-day Pro trial with no credit card, and you can export or delete everything at any time.

The practical shape of the fix for a Typebot builder: at the start of a session, your flow reads what the memory layer knows about this visitor (or this task) and prefills the variables that matter. During the session, key turns get saved back. The next session, next week, starts informed instead of blank. You keep Typebot's excellent in-session engine; you just stop pretending the session table is long-term memory.

The takeaway

Typebot remembers everything about the conversation it is having right now and nothing about the conversations it had before, unless you wire up persistence yourself. The Results table keeps a ledger, the Response ID variable keeps AI context alive within a session, and beyond that the platform is deliberately stateless. If your automation needs continuity across sessions, put the memory in a layer built for that job, and let Typebot do what it does best: run the flow.