Most WhatsApp integration projects stall in the same place, and it is never the part teams budget for. The messaging works on the first afternoon. What takes the remaining weeks is the plumbing around it: which number you may use, who owns it, where the consent record lives, what identity you join customers on, and what your system has to know about a 24-hour clock it does not control.
This guide covers what connecting the WhatsApp Business API to an existing stack actually requires — the decisions that are expensive to reverse, the constraints that behave like engineering problems rather than policy, and the cases where you should not integrate at all.
The number is a commitment, not a setting
A phone number can be connected to one Business Solution Provider at a time. That single fact drives most of the early decisions.
Use a dedicated number that is not currently active on WhatsApp. A number already running the consumer app or the WhatsApp Business app has to be migrated, and migration means downtime on that number. Taking your main customer-service line through this without planning is how a team discovers the constraint on a Monday morning.
Expect a verification gate before real volume. Business verification in Meta's Business Manager is what lifts you past the starter tier — until it clears, you are limited to a small number of unique recipients per day, which is fine for testing and useless for a campaign. Start verification early; it needs company documents and a verifiable website, and it is the step most likely to be waiting on someone else.
Decide who owns the asset. If the BSP holds the number on your behalf, leaving later requires portability, not just an export. Ask before you sign, not when you want out. We cover the switching mechanics in choosing a WhatsApp BSP.
Consent is a record, not a checkbox
Every integration needs a place where opt-in lives, and it needs to be a record you could show someone: who consented, when, through which surface, to what wording.
The mistake is storing a boolean. A boolean tells you the customer is opted in; it does not tell you whether you can prove it, and it does not survive a channel question — consent collected for email does not extend to WhatsApp. Store the timestamp, the source, and the exact text shown, and keep it joined to the contact rather than in a form-submission log nobody can query.
The rules themselves, and how Italian brands document them under the GDPR, are in our guide to WhatsApp opt-in.
The identity problem nobody plans for
WhatsApp is keyed on the phone number. Most e-commerce stacks and CRMs are keyed on email. Integrating the two means deciding, explicitly, what a customer is.
You will find duplicates immediately: the same human as an email-only record and a phone-only record. You will find numbers stored in five formats, some without a country code, which do not match anything until normalised to E.164. And you will find customers whose WhatsApp number is not the number on their order.
Normalise on write, not on read, and decide up front whether the phone number or the CRM id is the primary key for a conversation. Doing this after you have a few thousand conversations is a migration.
The 24-hour window is an engineering constraint
Policy documents describe the customer-service window as a rule. In your system it behaves as state: when a customer messages you, a window opens, and while it is open you can reply freely; once it closes, reaching them again requires a pre-approved template, which costs money and has a category.
That means your application has to know whether a window is open before it decides how to send. Systems that skip this send everything as a template and pay for messages that could have been free, or attempt free replies that silently fail. Either way the bug is invisible on a dashboard until the invoice arrives.
Templates add their own state: each one is submitted for approval, and approval is not instant. Queue anything time-sensitive well ahead of when you need it. The mechanics of the window and the message types are in the 24-hour window and WhatsApp Business API marketing.
What flows back, and where it should land
An integration that only sends is half-built. Decide before launch what the rest of the stack receives:
Delivery and read state per message, joined to the customer — otherwise you cannot tell a failed campaign from an unpopular one.
Inbound messages, routed somewhere a human can see them. This is the requirement teams underestimate: opening a channel creates an obligation to answer it.
The conversation itself, or at least a summary, on the customer record. Support agents who cannot see what the automated assistant already said will contradict it.
What breaks in month two
Quality rating. Meta scores your number on how recipients react — blocks and reports push it down, and a low rating cuts your messaging limits. This is the mechanism that punishes bought lists and over-sending, and it degrades gradually rather than failing loudly.
Template rejection at the worst moment. A template that reads like marketing but was submitted as utility gets rejected or reclassified, and the campaign that depended on it misses its window.
Nobody answering. The commonest failure is organisational, not technical: inbound volume arrives and there is no rota. An unanswered WhatsApp reads worse to a customer than no WhatsApp at all.
When not to integrate
If your monthly volume is low and your use case is one-to-one conversation, the free WhatsApp Business app does the job and the API is overhead you do not need. The API earns its complexity when you need automation, multiple agents on one number, or a connection to your order data.
If you have no one to staff the inbox, do not open it. If your list was not collected with consent for this channel, do not import it — the quality rating will find you. And if the only goal is broadcast, check whether the economics work before building: every business-initiated message has a price, which is covered in what WhatsApp Business API costs.
The order that works
Number and verification first, because they have external waiting time. Consent record second, because retrofitting proof is impossible. Identity normalisation third, before conversation volume makes it a migration. Then window-aware sending, then templates, then automation. Teams that invert this order ship a demo in a week and spend a quarter making it safe to use.
For the concierge layer that sits on top of this once the plumbing is done, see TikJoy's WhatsApp AI Concierge.