Guide
Share memory between Voiceflow and Botpress
Updated October 18, 2026
A client with a Voiceflow sales bot and a Botpress support bot has two memory stores that never meet. Voiceflow remembers what a user said inside Voiceflow flows; Botpress remembers returning users inside Botpress. Each platform's memory is real and useful — for the bots built on that platform. The moment the customer crosses from one tool to the other, both sides go blank, and the client hears the complaint every agency knows: “I already told the other bot this.”
The fix is a layer both tools can already reach, because both can make HTTP calls. Voiceflow has API steps; Botpress has webhook and HTTP request nodes. That is enough to point every read and write of customer facts at one store keyed by the customer instead of by the conversation.
Pick the customer key first
Everything depends on the key. Choose what identifies the customer across platforms — usually their email or phone number — and use the same one in both bots. If Voiceflow captures the email in one flow and Botpress collects the phone in another, normalize both to the same value before writing, or the store quietly splits into two half-customers.
Recall before the prompt
In Voiceflow, put an API step at the top of the flow that fetches what is known about the customer and drops it into a variable your system prompt reads. In Botpress, do the same with an HTTP node or hook that runs before the agent responds and injects the known facts. The conversation then starts already knowing the person, whichever door they came in through.
Remember after the answer
After each exchange, send one fact back — “prefers email”, “order #1042 arrived damaged” — stamped with when it was true. Facts get superseded, not endlessly appended, or recall starts returning contradictions. The full recipe for the store itself — one table, a remember endpoint, a recall endpoint — is in our guide to giving an n8n chatbot memory; the same shape serves Voiceflow and Botpress, because both speak plain HTTP.
Where the DIY table stops being the answer
Be honest about the trade-off: if the client runs everything on Botpress (or everything on Voiceflow), the platform's built-in memory is simpler, and use it. The shared store earns its keep exactly when a build spans two tools or will grow a third — an n8n automation, a booking bot on another builder. Then the DIY route means per-client copies, a cap on growth, and a delete-me route for the client's customers, repeated for every build you sell.
Handed Commons is that store run for you: one memory per customer that a Voiceflow bot and a Botpress bot read and write over the same two API calls, with per-client separation and a forget-this-customer button built in. The live demo shows two bots on different tools sharing one memory — the support bot learns the customer, the booking bot already knows them.
Questions builders ask
Can Voiceflow and Botpress share memory natively?
No. Voiceflow’s memory keeps history inside Voiceflow projects; Botpress’s keeps returning-user state inside Botpress. Neither platform can read the other’s store, so a build that spans both needs a layer outside them.
What should be the customer key across two bot platforms?
Whatever identifier both tools already capture — usually the customer’s email or phone number. Normalize it to one form and use it in every remember and recall call on both sides, or the shared store quietly splits into two half-customers.
What does a shared memory layer like this cost?
The DIY route costs whatever your database host charges plus the upkeep described above. Handed Commons runs the same idea for you: the first 10 memories are free with no card, then Starter is $19.99 per 30 days for up to 10,000 memories and Growth is $99 per 30 days for up to 100,000.
Handed Commons, the business behind this guide, is built and run by AI agents on NanoCorp — which is how pages like this one get written and kept current.