WhatsApp Business API: from a shared phone to a team inbox

Most businesses in India already run on WhatsApp — on one number, on one phone, in one person's pocket. Here is what actually changes when you move that number to the Business API, and how we built a team inbox on top of it.

Ketul Shah — Anekant AI

The problem: a business that lives on one phone

Walk into almost any small or mid-size business in India and you will find the same setup. There is one WhatsApp number that customers message for orders, quotes, complaints, and payment confirmations. That number lives on one physical phone. Whoever holds the phone is customer support.

It works — right up until it doesn't. Two staff members can't answer at the same time, so messages queue behind one pair of thumbs. A conversation started by the morning shift is invisible to the evening shift, so customers repeat themselves. When the person holding the phone goes on leave, the channel effectively closes. When they resign, the history often walks out the door with them. And because everything is manual, there is no automation at all: no auto-acknowledgement, no order-status updates, no way to send a hundred customers a delivery notification without forwarding it a hundred times.

None of this is a people problem. It is an architecture problem. WhatsApp on a phone is a personal messaging app being asked to behave like business infrastructure. The fix is to change the substrate, not to buy a second phone.

What the Business API actually changes — and its rules

The WhatsApp Business API (also called the Cloud API) removes the phone from the picture entirely. Your number is registered against the API, and there is no app and no handset. Instead, two things happen:

• Inbound messages arrive as webhooks. When a customer messages you, WhatsApp's servers POST a JSON payload to a URL you control. Your software decides what to do with it — store it, route it, answer it.
• Outbound messages are API calls. Your software sends replies by calling the API, from anywhere: a dashboard, a cron job, an order-processing pipeline.

That flexibility comes with rules, and it is worth being honest about them because they shape everything you build:

• The 24-hour customer service window. When a customer messages you, a window opens during which you can reply freely with any content. Twenty-four hours after their last message, the window closes. Outside it, you cannot send free-form text.
• Templates for outbound. To message someone outside the window — a delivery update, a payment reminder, a re-engagement nudge — you must use a message template that WhatsApp has reviewed and approved in advance. Templates have categories (utility, marketing, authentication), placeholders for variables, and they can be rejected or later revoked if they attract complaints.
• Media is indirect. An inbound photo or PDF arrives as a media ID, not a file. You call the API with that ID to get a short-lived download URL, fetch the bytes, and store them yourself. If you don't, the media is gone when the URL expires.

These constraints exist to keep WhatsApp from becoming an SMS-style spam channel, and they largely work. Build with them rather than against them and the platform is dependable. Try to route around them and you will lose the number.

What we built: the Anekant WA Dashboard

For our WA Dashboard project, we turned this into a chat operations console: a team inbox on top of the Business API, running on a serverless edge stack — edge functions handling webhooks and API calls, a SQL store for conversations and messages, and object storage for media. No servers to patch, near-zero idle cost, and the webhook endpoint answers from a location close to WhatsApp's own infrastructure.

The data flow is simple to describe: webhook receiver → message store → team inbox UI. Every inbound event is verified, normalized, and written to SQL as a message row attached to a conversation. The inbox UI reads from that store, so every agent sees every conversation with full history — who said what, when, and which teammate replied.

The receiver itself is the most load-bearing piece, and it is small:

export async function handleWebhook(req, env) {
  const body = await req.json();
  const msg = body.entry?.[0]?.changes?.[0]?.value?.messages?.[0];
  if (!msg) return new Response("ok"); // status update, not a message

  // WhatsApp retries — insert must be idempotent on message id
  await env.DB.prepare(
    "INSERT OR IGNORE INTO messages (wa_id, from_no, type, body) VALUES (?,?,?,?)"
  ).bind(msg.id, msg.from, msg.type, msg.text?.body ?? "").run();

  if (msg.type !== "text")
    await env.MEDIA_QUEUE.send({ mediaId: msg[msg.type]?.id }); // fetch & archive async

  return new Response("ok"); // ack fast; everything else is downstream
}

On top of the store sit the operational features that make it a team tool rather than a mirror of the phone:

• Assignment. Conversations can be claimed or assigned, so "who is handling this customer" is a field in the database, not a shout across the office.
• Template management. Templates are created, submitted for approval, and tracked inside the dashboard, with their approval status visible — so outbound campaigns only ever use templates that WhatsApp will actually accept.
• Automation hooks. Inbound messages can trigger flows: auto-acknowledgements inside the service window, order-status lookups, and an LLM step that drafts a suggested reply from the conversation history. The draft goes to a human, who edits or approves before anything is sent. The model accelerates the agent; it does not impersonate the business.

Lessons for developers

If you are building on the Business API yourself, four things matter more than any framework choice.

Make webhook processing idempotent. WhatsApp retries deliveries when your endpoint is slow or returns an error, and the same message can arrive more than once. Every payload carries a stable message ID — key your writes on it (an INSERT OR IGNORE or an upsert) so a retry is a no-op, not a duplicate row and a duplicate auto-reply. Acknowledge with a 200 quickly and push slow work (media downloads, LLM calls) onto a queue.

Separate inbound and outbound paths. Receiving webhooks and sending API calls have different failure modes, different rate limits, and different retry semantics. Keeping them as distinct code paths — receiver writes to the store, a sender consumes an outbox — means a stuck outbound campaign never blocks inbound receipt, and every send attempt has an audit trail.

Decide media retention up front. Since you must fetch and store media yourself, you own the storage bill and the compliance question. Object storage makes archiving cheap, but "keep everything forever" is a policy, not a default. Decide per media type what you keep and for how long, and record the decision in code.

Design for template rejection. Treat template approval as a pipeline stage that can fail, because it will: a rejected template with no fallback means a silent gap in customer communication. Track approval status in your data model, keep a plain utility template as a fallback, and never hard-code a template name into a flow without checking its status first.

What this gets a business

For clients, the payoff is less about technology and more about what stops going wrong.

Continuity. The conversation history belongs to the business, in its own database, regardless of who is on shift or who resigns. A new hire opens the inbox and sees every customer's full context from day one.

Accountability. Every conversation has an owner and every reply has an author. Response times become measurable, and "I thought you replied to them" stops being a sentence anyone says.

Automation without spam. Because the platform's own rules — the service window, approved templates — are enforced in the tooling, automation stays on the right side of the line. Customers get instant acknowledgements and useful updates, not broadcast noise, and the number's reputation stays intact.

If your business runs on a WhatsApp number that lives in one person's pocket, this is a solved problem. You can read more about our WhatsApp and messaging automation services, or see the WA Dashboard in our portfolio.