The n8n Chat Trigger node: complete guide to the conversational entry point

Every conversational n8n workflow starts with the same node: the Chat Trigger. It receives the user's messages, turns them into workable data (chatInput, sessionId) and kicks off the rest of the workflow — typically an AI Agent node. This guide covers the node itself: its two modes (chat hosted by n8n vs chat embedded in your own site), its key options, the data it emits, and how it differs from a regular Webhook. For the full "chat widget on my website" use case, see our dedicated article on adding an AI chat widget to a website — here we focus on the node.

What the Chat Trigger is for

The Chat Trigger is the conversational entry point of a workflow: it runs every time a user sends a message through a chat interface connected to the workflow. It plays three roles:

• Exposing a chat interface or endpoint: a chat page hosted by n8n and reachable by URL, or a webhook-style endpoint that your own front end calls.
• Normalizing the incoming message: whatever the channel, the workflow receives the same structure — the text in chatInput, the conversation identifier in sessionId.
• Carrying the session: the sessionId generated by the node is the key that lets memory nodes rebuild the conversation history on every turn.

Do not confuse it with the editor's "Chat" test panel: when you talk to your workflow from the canvas, the Chat Trigger is indeed what runs, but in manual mode, meant for development. As long as the Make Chat Publicly Available option is off, nobody but you can talk to the workflow. The test panel is a debugging tool; the node is the production front door.

The two modes: Hosted Chat and Embedded Chat

The node's Mode parameter offers two distinct behaviors.

Hosted Chat: the turnkey interface

In Hosted Chat mode, n8n generates and hosts a complete chat page, reachable through a public URL shown in the node (once the workflow is active and public access is enabled). You write zero front-end code: title, subtitle, input placeholder and Initial Message(s) (the welcome messages displayed when the user lands on the page) are configured directly in the node. It is the recommended mode for sharing an internal assistant, prototyping a RAG chatbot or letting a client test an agent, without deploying anything.

Embedded Chat: the widget in your own front end

In Embedded Chat mode, the node no longer serves a page: it exposes an endpoint that your own interface calls. The most common setup is the official @n8n/chat package, which ships a ready-made widget:

<link href="https://cdn.jsdelivr.net/npm/@n8n/chat/dist/style.css" rel="stylesheet" />
<script type="module">
  import { createChat } from 'https://cdn.jsdelivr.net/npm/@n8n/chat/dist/chat.bundle.es.js';
  createChat({
    webhookUrl: 'YOUR_CHAT_TRIGGER_URL',
    mode: 'window' // or 'fullscreen'
  });
</script>

The widget sends messages in the exact format the node expects: the chatInput and sessionId keys are the defaults of the chatInputKey and chatSessionKey options of createChat. You can also call the endpoint from a custom application as long as you respect that contract. In this mode, fill in the Allowed Origins (CORS) option with the domains allowed to call the endpoint — the same hardening logic as securing an n8n webhook.

The options that matter

Four settings deserve your attention:

1. Make Chat Publicly Available: while this toggle is off, the chat is only reachable from the editor's test panel. Turn it on (and activate the workflow) to open the public URL or the embedded endpoint.
2. Authentication: three levels — None (open access), Basic Auth (username/password in an n8n credential) and n8n User Auth (restricted to users logged in to your instance). For an internal assistant, n8n User Auth is the simplest; for a public widget, you stay on None with CORS filtering and guardrails on the agent side.
3. Allow File Uploads: lets the user attach files, which arrive in the workflow as binary data alongside the text. The Allowed File Mime Types option restricts accepted types (for example image/*,application/pdf) — left empty, every type gets through, which is rarely what you want.
4. Response Mode: determines how the answer travels back. When Last Node Finishes returns the output of the last node; a mode based on dedicated response nodes lets you send several messages mid-execution — the same logic as the Respond to Webhook node for regular webhooks; and Streaming Response streams tokens as they are generated, provided the downstream node supports it — the AI Agent does. For a chat, streaming changes everything: the answer starts immediately instead of leaving the user staring at a spinner.

A Load Previous Session option can also reload a session's previous messages when the user comes back — useful with the embedded widget, whose loadPreviousSession parameter is on by default.

The data you receive: chatInput and sessionId

On every message, the node outputs an item whose two essential fields are:

{
  "sessionId": "8d2f4a…",
  "chatInput": "What are your opening hours?"
}

{{ $json.chatInput }} is the user's text: it is what you pass as the prompt to the agent or an LLM chain. {{ $json.sessionId }} is the conversation identifier, stable for the whole session: it is the keystone of memory. Memory nodes (Simple Memory, Postgres Chat Memory, Redis…) use it by default to store and retrieve history — the full mechanics are covered in our guide to conversation memory for AI agents. Without a consistent sessionId, every message would start from scratch.

Caring about conversational continuity is not a nicety: the study by Brandtzaeg and Følstad published in 2017, "Why People Use Chatbots" (Google Scholar), found that the top motivation of chatbot users is productivity — getting fast, efficient help — which presupposes not repeating your context on every message. And a study by Adam, Wessel and Benlian published in 2021 in Electronic Markets, "AI-based chatbots in customer service and their effects on user compliance" (Google Scholar), showed that human-like conversational cues significantly increase users' willingness to cooperate with a chatbot: welcome messages, dialogue continuity and fluid answers are not cosmetic.

The typical wiring: Chat Trigger → AI Agent

The standard pattern boils down to two main nodes:

1. Chat Trigger — receives chatInput and sessionId.
2. AI Agent — takes the message as its prompt; you attach a Chat Model (OpenAI, Anthropic, Mistral…), a Memory node (which picks up the sessionId automatically) and, if needed, custom tools.

The answer travels back to the interface according to the chosen Response Mode. For simple Q&A without tools, a Basic LLM Chain does the job — the trade-off is detailed in our comparison of Basic LLM Chain vs AI Agent.

Chat Trigger or regular Webhook?

Technically, the Chat Trigger is a specialized webhook. The practical differences with the Webhook node:

• Interface included: the Webhook offers no UI; the Chat Trigger brings a hosted page or an official widget.
• Normalized format: chatInput/sessionId are expected by n8n's whole AI ecosystem, whereas a Webhook leaves you to define your own contract.
• Native sessions: conversation continuity is handled for you; with a Webhook you would have to generate and carry a session identifier yourself.

The Webhook remains the right choice when the channel is not a web chat interface: for a WhatsApp chatbot, a Webhook receives messages from the Meta API and you map the phone number to a sessionId yourself.

Best practices and limits

• Never leave a public chat without guardrails: scope the agent tightly in its system message, enable authentication whenever your audience allows it, filter CORS origins in embedded mode.
• Test with the editor panel before opening public access: same data, zero exposure.
• Restrict uploads: only enable Allow File Uploads if the workflow actually does something with files, and lock down the MIME types.
• Watch the cost: a public chat wired to an LLM burns your tokens; plan monitoring and limits.
• The hosted interface stays generic: for deep customization, switch to embedded mode with @n8n/chat or a custom front end.

Key takeaways

The Chat Trigger turns n8n into a chatbot platform: it provides the interface (hosted, or embedded via @n8n/chat), normalizes every message into chatInput and sessionId, and carries the session that all conversation memory depends on. Pick the mode that fits your need, lock down access (authentication, CORS, file types), enable streaming for responsiveness, and wire it all to an AI Agent with memory. The node is simple; it is the rigor of its configuration that separates a prototype from a production assistant.