Blog · Developers · 4 min read · Published Nov 5, 2026 · Updated Nov 13, 2026

How to Build a WhatsApp Chatbot Using Node.js

Inbound webhook + reply API = a working chatbot skeleton in Node.js.

In brief

Inbound webhook + reply API = a working chatbot skeleton in Node.js.

Architecture

  1. FlareSend posts inbound messages to your webhook.
  2. Your Node app parses text or button payloads.
  3. You reply with /send-message using the instance API key.

See WhatsApp webhooks.

Minimal Express handler

app.post('/webhooks/whatsapp', async (req, res) => {
  const text = req.body?.message || '';
  // TODO: map intents, then reply via FlareSend API
  console.log('inbound', text);
  res.sendStatus(200);
});

Keep the first version short

Start with keyword replies (price, support, hours) before adding AI. Store conversation state in Redis or Postgres keyed by phone number. Always offer a human handoff path.

Production checklist

  • Public HTTPS endpoint
  • Fast 200 responses; process heavy work async
  • Idempotent handling of duplicate deliveries
  • Structured logging with phone hashes, not raw PII dumps
  • Circuit breakers when the send API is slow

Intent design without overbuilding

Five intents cover most SME bots: greeting, pricing, hours, human handoff, fallback. Ship those before NLP. When you add AI, constrain it with allow-listed tools and never let the model invent prices.

Session memory

Keep last intent, last order id, and language preference. Clear memory after a quiet period so the next conversation starts clean.

Handoff quality

When the bot escalates, pass a short summary to the human: what the user asked, what the bot tried, and any order id. Cold handoffs waste the automation investment.

Practical scenarios

Here are concrete situations teams solve with this topic.

Scenario A — early-stage product

You need to prove WhatsApp automation this week. Connect a QR-linked number, send a transactional message, and measure whether customers understand and act. Keep the copy short. Log every API response. Expand only after the first path is reliable.

Scenario B — growing SME

Volume is rising and manual WhatsApp replies are failing. Automate the top one or two events first (usually payment or OTP). Train support on what the system already sends. Add scheduling and webhooks after the basics are stable.

Scenario C — developer platform

You are embedding WhatsApp into your own SaaS. Wrap FlareSend behind your service layer so product code never hard-codes HTTP details. Use queues, idempotency keys, and environment-specific API keys. Document the contract for your teammates.

Quality bar before you go live

  1. Happy-path send works on a real phone.
  2. Failure path shows a clear customer message or retry.
  3. Disconnects are visible to an operator.
  4. Consent or transactional justification is written down.
  5. Someone owns monitoring for the next 30 days.

Common mistakes

  • Treating WhatsApp like email blast infrastructure
  • Mixing marketing copy into OTP or payment messages
  • Ignoring quiet hours across African timezones
  • Skipping idempotency on payment webhooks
  • Leaving staging keys pointed at production numbers

Fix those five and most production incidents disappear before they start.

Browse related solution pages from the footer Solutions menu, skim the FAQ for safety and pricing questions, and keep the API docs open while you implement. When you are ready, start the free trial and ship one real customer workflow end to end.

Field notes from production teams

Teams that succeed with WhatsApp automation treat it like payments infrastructure: monitored, idempotent, and owned by a named engineer. They write runbooks for disconnects, keep a staging number for tests, and review failed sends in the same standup as failed transactions. They also refuse to use the channel for unsolicited cold outreach, because reputation damage is expensive to reverse.

If you are mid-implementation, pick one customer journey, instrument it, and only then expand. Breadth without reliability creates noisy support queues. Depth with clear metrics creates a channel customers trust.

Finally, keep FlareSend docs and your internal README linked from the same place. On-call engineers should not hunt for curl examples during an incident.

Implementation checklist

  • Confirm consent or transactional context before sending.
  • Store API responses for support audits.
  • Prefer background jobs so web requests stay fast.
  • Respect quiet hours for your customers' timezones.
  • Link every automation to a clear customer benefit.

Try FlareSend

Connect WhatsApp in minutes and send OTPs, notifications, or bulk messages from one API.

Start free 4-day trial View pricing