WhatsApp Flows vs Chatbots in India (2026): Technical Implementation Guide with JSON Examples

WhatsApp Flows are not a replacement for chatbots — they are a different surface for a different job. A chatbot lives inside the message thread and handles open-ended conversation. A Flow opens a full-screen, app-like form on top of WhatsApp and handles structured data collection. For Indian D2C brands, tech founders, and marketing agencies running on the official WhatsApp Business API in 2026, picking the wrong one costs 30–50% of your conversion rate. This guide gives you the technical decision framework, the JSON structure Meta actually expects, the `endpoint_uri` webhook contract, the template approval gotchas that kill production launches, and the Jan 2026 per-message cost math you need to compare the two paths economically.

What a WhatsApp Flow Actually Is

A WhatsApp Flow is a Meta-hosted, declarative UI that renders inside WhatsApp as a full-screen, multi-page interactive form. You ship a JSON document describing screens, components, and routing; Meta's WhatsApp client renders it natively. The user never leaves WhatsApp, you collect structured fields in a single session, and submission is delivered to your backend via a secured `endpoint_uri` webhook. Flows support text inputs, dropdowns, radios, checkboxes, date pickers, image displays, and footer CTAs — the full set is in Meta's Flow JSON schema reference. The payload is a fixed, schema-validated object, not a freeform transcript.

What a Flow is Not

• Not a chatbot. It does not accept open-ended intent, it does not route based on natural language, and it does not hold conversation state across messages.
• Not a substitute for a web landing page. Meta throttles component count per screen, restricts HTML rendering, and only allows text/input primitives.
• Not a fire-and-forget template. Each Flow must be built, submitted to Meta, approved, and then wrapped in a flow-enabled message template before it can be sent.

Flows vs Chatbots: The Decision Matrix

Use a chatbot when the user's next best action is open-ended, conditional, or needs branching logic over many turns. Use a Flow when the user's next best action is to fill a known set of fields. Teams that switch lead capture from a question-by-question chatbot to a single WhatsApp Flow routinely see completion rates rise 40–60% because every field lives on one screen and back-navigation is native.

Dimension	Chatbot (in-thread)	WhatsApp Flow (full-screen)
Input style	One question per message bubble	Multi-field form on a single screen
Completion rate (typical)	35–55%	60–85%
Branching logic	Native: per-node conditions, delays, attribute-based paths	Limited: only linear screen-to-screen transitions and form validation
Open-ended NLP	Supported via AI node or keyword triggers	Not supported
Agent handoff	Supported	Not directly — must exit Flow and enter chat thread
Approval latency	None (instant publish)	Meta review: typically 24–72 hours per new Flow
Data submission	Message-by-message via webhook	Single payload via `endpoint_uri` at submit
Best use case	Lead qualification, customer support, FAQ routing, up-sell	Booking, onboarding, KYC, feedback, structured lead capture

Indian D2C Use Cases with 2026 Benchmarks

Indian D2C brands running on the WhatsApp Business API in 2026 operate under the revised Meta pricing structure that took effect January 1, 2026. Marketing messages moved from ₹0.7846 to ₹0.8631 per message — a 10% increase. Utility and authentication messages remain around ₹0.115 per message. The pricing shift changed the economics of long chatbot sequences, because every outbound template counts toward a marketing or utility category, while a single Flow invocation plus its CTA template is often billable as one interaction. The short version: Flows are cheaper per qualified lead when the task is a form; chatbots are cheaper when the task is conversation.

Flow JSON: The Minimum Viable Schema

Every WhatsApp Flow is defined by a Flow JSON document. Meta's current schema version is 7.1. A production-ready lead-capture Flow looks like this at the minimum:

{
  "version": "7.1",
  "data_api_version": "3.0",
  "routing_model": {
    "LEAD_FORM": ["THANKS"],
    "THANKS": []
  },
  "screens": [
    {
      "id": "LEAD_FORM",
      "title": "Get your quote",
      "data": {},
      "layout": {
        "type": "SingleColumnLayout",
        "children": [
          { "type": "TextInput", "name": "full_name", "label": "Full name", "required": true },
          { "type": "TextInput", "name": "pincode", "label": "Pincode", "input-type": "number", "required": true },
          {
            "type": "Dropdown",
            "name": "category",
            "label": "Preferred category",
            "data-source": [
              { "id": "apparel", "title": "Apparel" },
              { "id": "beauty", "title": "Beauty" },
              { "id": "home", "title": "Home & Living" }
            ],
            "required": true
          },
          { "type": "OptIn", "name": "consent", "label": "I agree to receive updates on WhatsApp", "required": true },
          {
            "type": "Footer",
            "label": "Submit",
            "on-click-action": {
              "name": "data_exchange",
              "payload": {
                "full_name": "${form.full_name}",
                "pincode": "${form.pincode}",
                "category": "${form.category}",
                "consent": "${form.consent}"
              }
            }
          }
        ]
      }
    },
    {
      "id": "THANKS",
      "title": "Thank you",
      "terminal": true,
      "data": {},
      "layout": {
        "type": "SingleColumnLayout",
        "children": [
          { "type": "TextBody", "text": "Your request is recorded. We'll WhatsApp you within 15 minutes." }
        ]
      }
    }
  ]
}

Three JSON Gotchas That Fail Meta Approval

• Missing `routing_model`. Every screen that links to another must declare the destination in `routing_model`. Terminal screens declare an empty array. Meta rejects submissions with orphan transitions.
• Wrong `data_api_version`. The API version used by your endpoint must match the Flow JSON header. Mismatched versions silently drop screen-to-screen data updates.
• Over-long titles. Screen title strings longer than 30 characters will be truncated on Android clients and may fail review on iOS.

endpoint_uri: The Webhook Contract You Cannot Skip

The `endpoint_uri` is the single most misunderstood part of WhatsApp Flows. It is a Laravel (or any server) endpoint that Meta POSTs encrypted payloads to at four moments: initial screen load, data exchange on screen transitions, final submission, and error retries. Every payload is encrypted with the Flow-specific public key you register with Meta; you decrypt using AES-128-GCM with an RSA-wrapped session key. Meta expects a response within 10 seconds. If you return the wrong `screen` identifier, the user sees an error and abandons the Flow.

The inbound payload shape is:

{
  "version": "3.0",
  "action": "data_exchange",
  "screen": "LEAD_FORM",
  "data": {
    "full_name": "Priya Sharma",
    "pincode": "400001",
    "category": "apparel",
    "consent": true
  },
  "flow_token": "uuid-issued-by-business-server"
}

Your response must name the next screen or mark the Flow complete:

{
  "version": "3.0",
  "screen": "THANKS",
  "data": {}
}

On RichAutomate, the `WhatsappFlowController` handles decryption, validates the `flow_token` against the tenant-scoped flow run, writes the collected fields to `contact_attributes`, dispatches the follow-up utility template via the queued `SendMessageJob`, and returns the next screen ID — all inside the 10-second budget Meta enforces.

Template Approval: The Silent Launch Blocker

You cannot send a Flow without wrapping it in an approved message template of type Flow. The template itself must be submitted separately for Meta review, even if the underlying Flow is already approved. In practice this means launch day has two dependencies: Flow approval (typically 24–72 hours) and Template approval (typically 24–48 hours). Both stages can reject for different reasons. Build two full days of buffer into any campaign launch that uses a new Flow.

• Template category matters for cost. A Flow wrapped in a Marketing template is billed as Marketing (₹0.8631 per conversation in India, Jan 2026). A Flow wrapped in a Utility template sent inside a 24-hour service window can be billed as Utility (approximately ₹0.115).
• Pre-filled params leak user data. Do not send PII as template header or body variables if the template may be cached by Meta. Always pass contextual data via the Flow's `data_api_version` exchange, not via the outer template.
• Naming conventions survive. Template names cannot be renamed once submitted. Use `lead_v1_apparel_in` format so you can iterate without orphaning analytics.

Cost Economics: Flows vs Chatbots at 2026 Rates

At Meta's January 2026 India rates — Marketing ₹0.8631, Utility ₹0.115, Authentication ₹0.115, and free service messages inside the 24-hour window — the unit economics of Flows and chatbots diverge sharply.

Scenario	Chatbot (8-turn qualification)	WhatsApp Flow (single form)
Initial Marketing template	₹0.8631	₹0.8631
Reply turns (service window, inbound free)	0	0
Outbound qualifying questions	Service free (in-window)	N/A (inside Flow)
Utility follow-up after completion	₹0.115	₹0.115
Total Meta cost per lead initiated	₹0.9781	₹0.9781
Completion rate (typical)	44%	72%
Cost per qualified lead	₹2.22	₹1.36

The raw Meta cost is identical. The difference is entirely in completion rate. Anywhere you can express your data collection as a form rather than a conversation, Flows win on cost per acquired lead even when sent through a Marketing template.

When Chatbots Still Win

• Support queries. "Where is my order?" / "I want to cancel" / "Change my address" all require intent classification and conditional branching. Flows cannot do this.
• Up-sell and cross-sell. Decisions depend on purchase history and real-time availability. The conversational loop — show, ask, show, confirm — maps poorly to a form.
• Agent handoff. If 10–20% of conversations need a human, the chatbot can route. The Flow cannot.
• Long-running engagement. Drip campaigns that span days need conditional wait states, not a single-session form.

The Dual-Engine Pattern: Use Both

Mature Indian D2C stacks in 2026 run both engines side by side. Marketing campaigns enter through a Flow for lead capture. The moment the Flow submits, a chatbot takes over with qualification logic, product recommendations, and human handoff triggers. The Flow owns acquisition; the chatbot owns conversation. RichAutomate was designed this way from day one: `WhatsappFlowController` handles Meta Native Flows, `FlowExecutionService` drives the custom chatbot graph, and both can hand control to each other through shared `contact_attributes`.

Five Common Implementation Mistakes

1. Treating a Flow as a silver bullet. Teams replace their entire chatbot with a 7-screen Flow and watch completion collapse to 18%. A Flow is a focused form, not a funnel.
2. Skipping the encryption rotation schedule. Meta requires Flow public keys to be rotated periodically. Forgetting this causes Flows to silently fail for a subset of users until the key is refreshed.
3. Over-fetching on the `endpoint_uri`. Some teams query the full product catalog on every `data_exchange` hit. You have 10 seconds total. Cache upstream and pre-compute.
4. Sending PII in template variables. Meta caches template renders. Personally identifiable data must flow through the encrypted Flow channel, not the unencrypted template header.
5. Ignoring the template category trap. A Flow that gathers order-update preferences, wrapped in a Marketing template, pays 7.5× more per send than the same Flow wrapped in a Utility template inside the service window.

Decision Checklist Before You Build

1. Is the task a known set of fields? → Flow. Is it open-ended conversation? → Chatbot.
2. Do you need agent handoff on the same screen? → Chatbot.
3. Does your data require real-time validation from your backend? → Flow with `endpoint_uri` data exchange.
4. Will the user need to return later and continue? → Chatbot (persistent state).
5. Is conversion rate your primary metric? → Flow when the task is a form.
6. Do you have 3–5 business days of approval buffer? → If no, launch chatbot first and migrate to Flow later.