Does the exported bot depend on FlowBot at runtime?

No — the ZIP is a standalone Node.js + Express project with its own engine copy. It never calls FlowBot's servers, works offline from the platform, and keeps running if FlowBot disappears tomorrow.

Can I modify the exported code?

Yes, that's the point — it's readable JavaScript: the flow as a JSON structure plus an interpreter function. Add routes, swap the session store, wire in your logger; it's your codebase after export.

Which languages does the export support?

Node.js (Express). The flow itself is plain JSON, so porting the interpreter to another language is straightforward if you need to — the engine is a few hundred lines of deterministic logic.

How do I call my backend from a flow?

Use the HTTP Request block (or an api step in a custom block): method, URL, headers and body support {variable} interpolation, a JSON path picks the response field to store, and a second output port handles errors.

The WhatsApp bot builder that exports real code

Writing a WhatsApp bot from scratch means webhook plumbing, provider payload parsing, session state, reply formatting — a day of boilerplate before the first useful reply. FlowBot treats the visual canvas as a code generator: design the conversation as a flowchart, test it, then export a standalone Node.js + Express project you own and extend. No SDK lock-in, no phone-home, no platform runtime.

What's in the exported ZIP

server.js — the complete bot: your flow as data, the deterministic engine that interprets it, and the webhook endpoint for your provider (Twilio TwiML, Meta Graph API, Green API or Whapi REST).
package.json — minimal dependencies, npm start and you're live on any Node 18+ host.
.env.example + README.md — provider credentials, PORT config, and deploy notes (Render, Railway, a VPS, anywhere).

The exported engine is the same engine that runs in FlowBot's simulator and hosted webhooks — behavior is identical by construction, so what you tested is what ships.

Built for integration, not isolation

HTTP Request block. Call your own API mid-flow — {vars} interpolate into URL, headers and body; pick a field from the JSON response into a session variable and branch on failure.
Custom blocks. Chain say / ask / set / api / choice steps into reusable components — effectively writing functions visually, including API calls with error paths.
Deterministic by default. The engine interprets exactly the flowchart JSON. AI enters only where you place an AI block, scoped to that block, on your own Anthropic/OpenAI/Gemini key.
Sessions in Postgres on the hosted version; the exported bot keeps state in-process by default — swap in your own store if you need multi-instance.

Why not just write it by hand?

You can — the export shows you exactly what you'd have written. FlowBot earns its place as the spec + boilerplate layer: product people edit the flowchart, you review the diff of the flow JSON, and nobody re-implements "menu with three options that collects a phone number" for the fifth time. When requirements outgrow the canvas, export and keep coding — the flow JSON and engine are plain, readable JavaScript, not a proprietary bytecode.

Webhook architecture (hosted mode)

Each activated bot gets its own endpoint per provider — /whatsapp/:id (Twilio), /meta/webhook/:id (Cloud API with verify-token handshake), /green/webhook/:id, /whapi/webhook/:id. Incoming payloads are normalized to {from, text}, run through the engine against the stored session, and replies fan out via the provider's send API. The docs cover each provider's setup.

The WhatsApp bot builder that exports real code

What's in the exported ZIP

Built for integration, not isolation

Why not just write it by hand?

Webhook architecture (hosted mode)

Frequently asked questions

Build your WhatsApp bot in minutes — free