WhatsApp API Team Inbox: What the API Doesn't Give You

The WhatsApp API sends and receives messages. That's the whole product. It doesn't know which teammate owns a conversation, it won't stop two agents answering the same customer, and it doesn't keep a thread anyone can scroll back through. Teams usually find this out the week after the integration ships, when customer replies start piling up in a database table instead of in front of a person.

If you want a WhatsApp API team inbox, you either build one or buy one. This post lists what a team actually needs on top of the API, what building it involves, a starter data model, and how to decide between building, a provider's inbox and a workspace on your existing number.

The API is a pipe, not an inbox

Meta's Cloud API gives you a send endpoint and a stream of webhooks. Everything that makes WhatsApp workable for a team is your job.

What you get from the platform: an endpoint to send messages, webhooks for inbound messages and status updates, template management and media endpoints. What you don't get: a conversation list, users and logins, assignment, internal notes, search, stored history, a timer showing whether the 24-hour window is open, or any reporting on who answered what and how fast.

There's also an identity point that shapes everything else. One WhatsApp number is one identity to the customer. Ten agents can only answer from it through software that sits in front of the API, decides who replies, and records who did. That software is the inbox.

What a team inbox needs

Most of the value is in coordination, not messaging. Here's the checklist we'd hold any build or purchase against.

The API provides none of these directly. A few, like message status, come from webhooks you have to store and display.

What building one involves

A webhook handler is a day's work. An inbox your team lives in all day is a product, with all the upkeep that implies.

The pieces, roughly in the order you'll hit them:

1. Ingestion. Answer Meta's verification request, check the X-Hub-Signature-256 header on every payload, acknowledge quickly, and push the work onto a queue. Our guide to WhatsApp API webhooks covers the details.
2. Storage. Conversations, messages, contacts and status transitions, deduplicated by WhatsApp message ID.
3. Real-time UI. WebSockets or server-sent events so new messages appear without a refresh, plus unread counts that stay correct across agents.
4. Sending. A queue per number, template selection when the window is closed, and handling for every error your agents will otherwise see as "it didn't send".
5. Auth, roles and audit. Logins, permissions and an activity log you can show a manager or an auditor.
6. Media. Download, store, preview and scan files customers send.
7. Identity. Business-scoped user IDs and usernames mean the phone number may be missing from webhooks, so contacts can't be keyed on phone alone.
8. Operations. Token rotation, on-call for webhook outages, backups and data deletion requests.

A starter schema shows how much of the inbox is coordination data rather than messages. One trick worth copying: store internal notes as messages with their own direction, so the timeline shows everything in order, and simply never send them to WhatsApp.

create table contacts (
  id          uuid primary key,
  bsuid       text unique,          -- business-scoped user ID from webhooks
  phone       text,                 -- may be null once usernames roll out
  name        text
);

create table conversations (
  id              uuid primary key,
  number_id       text not null,    -- your business phone number ID
  contact_id      uuid not null references contacts(id),
  assignee_id     uuid,             -- references your users table
  status          text not null default 'open',  -- open, pending, closed
  last_inbound_at timestamptz,      -- drives the 24-hour window check
  updated_at      timestamptz not null default now()
);

create table messages (
  id              uuid primary key,
  conversation_id uuid not null references conversations(id),
  wamid           text unique,      -- WhatsApp message ID, null for notes
  direction       text not null,    -- in, out, note
  author_id       uuid,             -- agent who wrote it; null for inbound
  body            text,
  status          text,             -- sent, delivered, read, failed
  created_at      timestamptz not null default now()
);

Everything above this schema, the assignment rules, the SLA clock and the reports, is application logic you'll keep extending as the team grows.

Build, buy a provider's inbox, or use a workspace

Build when WhatsApp is part of your product. Buy when it's part of your operations.

Before you buy anything, ask: does it show groups, can you see who replied to what, can you export your data, what happens to history when someone leaves, and does it charge per seat, per message, or both?

Where Tenashi fits

Tenashi is the inbox and CRM with an API underneath, running on the number you already have rather than the Cloud API. You link your WhatsApp or WhatsApp Business number by QR scan, and your team works one shared inbox of DMs and groups with assignment, notes and @mentions, tickets with SLAs, canned replies, roles and permissions, multiple numbers and dashboards. Under every chat sits a CRM: contacts, custom fields, deals on a drag-drop pipeline and follow-ups.

Messages your systems send through the API appear in that same inbox like any teammate's reply, and webhooks fire for messages sent from the inbox, automations or the phone itself, so your code and your people see the same history. The honest limit: because it isn't Meta's platform, you won't get templates, interactive buttons or a green tick, and sending is deliberately paced to human volumes. If you need those, a BSP inbox on the Cloud API is the better fit.

See every feature · Read the API docs

FAQ

Does the WhatsApp API include a team inbox?

No. Meta's Cloud API provides an endpoint to send messages and webhooks for inbound messages and statuses. Conversation lists, assignment, notes, roles, stored history and reporting are all left to the software you put in front of it, which is why most teams either build an inbox or use one from a provider.

Can multiple agents use one WhatsApp API number?

Yes, through an inbox. The number is one identity to customers, and any number of agents can reply from it as long as software coordinates who answers and records who sent what. Without assignment and collision warnings, agents end up double-replying or leaving chats unanswered because each assumes someone else has it.

What's the hardest part of building a WhatsApp inbox?

Usually not sending or receiving. It's everything around coordination and reliability: real-time updates across agents, correct unread counts, assignment rules, the 24-hour window check, media handling, and keeping webhook ingestion working during outages and token changes. Those pieces grow with your team, so plan to maintain them, not finish them.

Do messages sent by API show up in a team inbox?

Only if the inbox and the API share one message store. With a separate inbox product, API sends can be invisible to agents, who then reply without context. In Tenashi, messages sent through the API land in the shared inbox like any reply, and webhooks report messages sent from the inbox or typed on the phone.

Can I use a team inbox without the WhatsApp API?

Yes. Workspaces that link your existing number as a device give a team a shared inbox without Meta onboarding, templates or per-message fees, and they include the groups your number is in. They aren't the official platform, so they suit conversations with existing customers rather than high-volume alerts or bulk outreach.

---

The API is plumbing; the inbox is where your team actually works, and it's the part that decides whether customers get fast, consistent answers. If you'd rather start with the inbox and add the API when you need it, see every Tenashi feature. For the plumbing itself, read our complete guide to the WhatsApp API.