How to send follow-up questions to Gemini with correct thread history in n8n?

You send follow‑up questions to Gemini by always passing the full conversation history inside the contents array of your Gemini API request. In n8n, this means you must store the message history yourself

 

How to Send Follow‑Up Messages with Correct Thread History in n8n

 

The key idea: every time the user says something new, you take your stored conversation array, append the new user message, and send the entire updated array to Gemini. Gemini outputs a new assistant message, and you add that to the stored history as well.

This is the only reliable method in production because Gemini does not keep state across calls, and n8n does not keep "session memory" unless you build it.

 

• Gemini API requires full context in the contents field.
• n8n does not store conversation state for you—you need to store it.
• You update the stored array every time before sending the request.
• Then send the entire conversation array again to Gemini for the follow-up reply.

 

Practical Production Setup in n8n

 

The simplest stable pattern: store the conversation JSON in an n8n Variable using a “Set” node or in a database or in-memory store like Redis. This works even for long-running workflows.

Your stored conversation usually looks like this:

 

[
  { "role": "user", "parts": [{ "text": "Hello Gemini!" }] },
  { "role": "model", "parts": [{ "text": "Hello! How can I help?" }] }
]

 

Then when the user asks something new, you append:

 

{ "role": "user", "parts": [{ "text": "Can you explain photosynthesis?" }] }

 

Now you send the ENTIRE array again to Gemini, not only the new message.

 

How to Build This in n8n (Step‑by‑Step Logic)

 

This describes the logic flow inside n8n. You can implement it using regular nodes, no hacks needed.

• Webhook Trigger (or whatever your entry point is) receives the user’s new message.
• Retrieve Conversation This can be a Set node (storing in workflow data), or a DB node. If it’s the first message, initialize the array to [].
• Append New User Message Use a Function node to push the new role/user entry into the array.
• Send to Gemini Use an HTTP Request node with: POST https://generativelanguage.googleapis.com/v1/models/gemini-pro:generateContent?key=API\_KEY
• Append Model Response Take Gemini’s output text and push a new {"role":"model"} entry into your array.
• Store Updated History Write the new array back to your Set/DB/Redis/etc. Now you're ready for the next follow-up.

 

Example: Function Node to Append User Message

 

// inbound data from webhook
const userMessage = $json["message"]; 

// existing conversation history stored in previous node
const history = items[0].json.history || []; 

// push new user message
history.push({
  role: "user",
  parts: [{ text: userMessage }]
});

// return updated history
return [{ json: { history } }];

 

Example: HTTP Node Body for Gemini

 

{
  "contents": [
    { "role": "user", "parts": [{ "text": "Hello Gemini!" }] },
    { "role": "model", "parts": [{ "text": "Hello! How can I help?" }] },
    { "role": "user", "parts": [{ "text": "Can you explain photosynthesis?" }] }
  ]
}

 

Important Production Notes

 

• Do not rely on n8n's “current execution data” to store long conversations — executions can expire or time out.
• Use external storage (Postgres, Supabase, Redis, or even a Google Sheet) for multi-message conversations, especially if you expect long chats or parallel users.
• Always rebuild the full array before sending to Gemini. Missing history produces incorrect or inconsistent answers.
• Control token growth: If your history gets long, prune older messages before sending. Gemini handles multi-message threads well, but you should still manage length.

 

That’s the reliable production pattern: store the thread yourself, append new messages, and always send the entire conversation to Gemini in the contents array with each follow-up.