WhatsApp Business API: What to Settle Before You Write Any Code

Most teams approach a WhatsApp integration as an engineering problem. It isn't, not initially. The engineering is a few days of work. What actually determines whether the project ships is a set of commercial and policy decisions — which API flavour you're on, how your templates get approved, what each message costs, and the quality rating that can quietly throttle your number to a fraction of its capacity.

Getting these wrong doesn't produce a bug you can fix. It produces a rejected template two weeks before launch, or a restricted number after it.

This is the groundwork. The implementation walkthrough lives in a separate article; this one is what you settle first.

Which API you're actually on

Three options exist, and the naming is genuinely confusing because Meta has changed it more than once.

For almost everyone building today, the answer is Cloud API. Meta hosts it, there's no infrastructure, and new features land there first. The On-Premises API is on its way out — do not start a new project on it.

A BSP (Twilio, 360dialog, Wati and similar) is worth considering only if you want the messaging layer abstracted away, you need their support relationship, or your compliance team wants a contractual counterparty who isn't Meta. You pay a per-message markup for that. If you have engineers who can call a REST endpoint, you're paying for something you already have.

The two conversation types that govern everything

This is the single most important concept, and it drives your architecture, your costs, and your compliance risk.

User-initiated. The customer messages you first. This opens a 24-hour customer service window, during which you can reply freely with normal messages — no template, no approval. When the window closes you lose that freedom until they message again.

Business-initiated. You message the customer first, or you reply after the 24-hour window has closed. This requires two things: a pre-approved message template, and recorded prior opt-in from that customer.

Nearly every problem teams hit traces back to blurring this line. An AI agent answering inbound questions lives entirely inside the service window and is straightforward. An agent that proactively follows up on a cold lead is a completely different compliance posture, and it's the one that gets numbers restricted.

Design these as two separate code paths with different rules, not one "send message" function with a flag. The inbound path optimises for latency. The outbound path optimises for consent enforcement and rate control. Merging them means the strictest rules either apply everywhere — crippling your reply speed — or nowhere, risking your number.

Message templates and why they get rejected

Any business-initiated message needs a template approved by Meta in advance. Templates are submitted per language, and each falls into a category — marketing, utility, authentication, or service — which determines both approval strictness and price.

The category assignment is not yours to declare freely. Meta re-categorises templates it thinks you've labelled optimistically, and a "utility" template that reads like an advertisement will be reclassified as marketing and priced accordingly.

Common rejection causes, roughly in order of how often they bite:

1. Marketing content submitted as utility. A utility template must relate to a specific transaction the customer already has with you — an order update, an appointment reminder. "Check out our new service" is marketing regardless of what you call it.
2. Variable parameters with no example values. Every {{1}} needs a sample. Submissions without them are rejected automatically.
3. Variables doing structural work. A template that is almost entirely placeholders — so the final message could say anything — gets rejected as an attempt to bypass review.
4. Missing or broken opt-out language in marketing templates.
5. URL shorteners in the body. They obscure the destination and are treated as a risk signal.
6. Grammar and spelling, genuinely. Templates get rejected for looking unprofessional.

Approval typically lands within minutes to a day. Build the review latency into your launch plan anyway, and submit templates early — before the integration is finished, not after. A rejected template on launch week is a self-inflicted delay.

How pricing actually works

Meta moved away from the older per-24-hour-conversation model to per-message pricing for template messages. The structure to plan around:

• Template messages are billed per message, at a rate that varies by category and by the recipient's country. Marketing costs the most; authentication and utility are cheaper.
• Service conversations — you replying to a customer inside their 24-hour window — are free. This is the significant one for an inbound AI agent: answering customer questions costs you nothing on Meta's side.
• Country rates vary by more than an order of magnitude. Pakistan, India, Brazil, and the United States are all priced very differently.

Two planning consequences follow.

An inbound support and sales agent is extremely cheap to run. Your real cost is model inference, not messaging. That changes the ROI maths substantially versus what most people assume going in.

Proactive outreach is where the bill appears, and it scales linearly with volume. Model your cost per acquired customer against marketing template rates in your target countries before committing to an outbound strategy.

Rates change and they're country-specific. Pull current numbers from Meta's official rate card for your markets rather than trusting any figure quoted in an article — including this one.

Quality rating and messaging tiers

This is the mechanism most teams don't discover until it hurts them.

Every business number carries a quality rating — green, yellow, or red — derived largely from how recipients react. Blocks and "report business" actions push it down. Engagement holds it up.

Your number also sits in a messaging tier that caps how many unique customers you can start conversations with in a rolling 24 hours. Tiers scale up automatically as you demonstrate volume at good quality, and they scale down when quality falls.

The failure pattern is consistent: a company gets access, imports a contact list, blasts a marketing template to everyone, collects a wave of blocks within hours, drops to red, and gets tier-limited or restricted. The list wasn't opted in, and WhatsApp is far less tolerant of that than email ever was.

Practical defences, all of them cheap:

• Send to opted-in contacts only, and keep the timestamped record proving it.
• Ramp volume gradually. Do not go from zero to your tier ceiling on day one.
• Honour opt-outs instantly and broadly — accept STOP, UNSUBSCRIBE, CANCEL, QUIT and the obvious variants, and process them before any other logic runs.
• Watch the rating in the WhatsApp Manager dashboard. Yellow is a warning you still have time to act on.
• Give people a reason to reply. Engagement is the strongest positive signal available to you.

The setup sequence

Roughly the order things must happen, because several steps block others:

1. Meta Business Account, with business verification — official documents, legal entity name, address. Start this first; it's the longest pole and everything else waits on it.
2. WhatsApp Business Account created inside it.
3. A phone number not currently active on the consumer WhatsApp or WhatsApp Business apps. Migrating an in-use number means deleting its existing account and losing that chat history — decide deliberately.
4. Display name approval. It must plausibly match your verified business name.
5. A Meta app with WhatsApp added, giving you the phone number ID and access token.
6. Webhook URL registered and verified — a public HTTPS endpoint that answers Meta's challenge handshake.
7. Templates submitted for anything business-initiated.
8. A permanent access token via a System User. The token you get during setup is temporary and will expire mid-demo if you let it.

That last point catches people repeatedly. Generate a System User token before you go anywhere near production.

What to have ready before the first line of code

• Business verification started — it gates everything downstream
• A decision on the phone number, including whether you're migrating one already in use
• Your opt-in mechanism defined, and somewhere to store consent with timestamps
• Draft templates written and categorised honestly
• An escalation route for when the AI should hand off to a human
• Target-country pricing checked against your projected outreach volume

Settle these and the engineering is genuinely a short project. Skip them and you'll ship an integration that works perfectly in testing and gets blocked in production.

Get it set up properly

We handle WhatsApp Business API onboarding end to end — verification, templates, the Cloud API integration, and the AI agent behind it. If you want the commercial groundwork and the build handled together, talk to us about AI chatbot development.