WhatsApp Business Platform integration

What this service is

We integrate the WhatsApp Business Platform into our clients' existing systems. The customer keeps their own WhatsApp Business Account and their own relationship with Meta; we build and operate the engineering between that account and whatever they already run, whether that is a scheduling system, an order pipeline or a support desk.

This is delivered as engineering work for a specific business, not as a product anyone can sign up for. The distinction matters both commercially and for compliance, because it determines who is responsible for the message content and the customer data, and that answer needs to be unambiguous before any code is written.

Embedded Signup

Embedded Signup is how a business connects its own WhatsApp Business Account without handing anyone credentials. The flow runs inside Meta's interface, the business authorises the connection, and what comes back is a scoped token tied to that account.

The engineering around it is mostly about handling the unhappy paths properly: an authorisation abandoned halfway, a business that already has an account connected elsewhere, a phone number that fails verification, a token that is revoked later. Each has a defined behaviour and a state the system can recover from. Deauthorisation in particular is handled as a first-class event rather than as a stream of failing API calls that somebody notices the next morning.

Webhooks

Inbound messages, delivery receipts and status changes all arrive as webhooks, and webhook handling is where most integrations quietly go wrong.

Signatures are verified on every request, because an unverified webhook endpoint is an open door for anyone who learns the URL. Handlers acknowledge fast and do the real work asynchronously, since a slow handler causes retries and retries cause duplicates. Every handler is idempotent and keyed on the message identifier, because the same event will be delivered more than once and the system has to treat the second copy as a no-op rather than a second order.

Anything that cannot be processed is captured with its full context and surfaced to somebody, rather than swallowed. A dropped inbound message is a customer who thinks they have been ignored.

Templates and the messaging window

WhatsApp draws a hard line between replying inside an open customer service window and initiating contact outside one. Outside it, only approved message templates may be sent. Template approval takes time and can be refused, which makes it a delivery dependency rather than a detail.

We manage templates as versioned artefacts alongside the code, track their approval state, and build the sending logic so that it knows which window it is in and picks a legitimate path accordingly. A system that assumes it can always send a free-form message will work perfectly in testing and then fail against real customers.

Conversation state

A conversation is a long-running interaction that can pause for days, resume out of order, and be answered by a person who was not there at the start. It cannot be held in memory or inferred from the last message.

We model it explicitly: what stage the conversation is at, what it is waiting for, what has already been confirmed, and how it times out. That state lives in a database and is the same state the rest of the business systems read, so a conversation on WhatsApp and a record in the operational system cannot drift apart.

Data protection

Where we operate a WhatsApp integration for a client, the client decides what is collected and why, and we process it on their documented instructions. Our Privacy Policy sets out that split in full, along with retention periods and how anyone can have their data deleted. We do not use client conversation data to train models. If your obligations require a specific processing agreement, that is a conversation to have before the engagement starts, not after.