WhatsApp Business API Integration: What It Takes to Connect WhatsApp to Your CRM, ERP or Orders

A WhatsApp Business API integration connects WhatsApp to your software: incoming messages arrive at a webhook you host, and your system replies through Meta's Cloud API. The plumbing is the easy part: a verified webhook, a signature check on every delivery, and an API call to reply. The project is everything after: turning voice notes, photos and three messages in a row into a clean order or CRM update, asking when something is unclear, and replying in a way that respects WhatsApp's limits and its pricing. Below: the pieces, the limits, and what we learned running WhatsApp for a UAE ordering platform and for quotation approvals.

---

The pieces

1. A WhatsApp Business Account in Meta's business tools, with your business verified.
2. A phone number registered on the Cloud API, with an approved display name. Plan which number: the one customers already message is the one worth connecting.
3. A system user access token for your server, so the integration doesn't depend on someone's personal login.
4. A webhook: a URL Meta calls with every incoming message and every delivery status.
5. Approved templates for anything you send outside the 24-hour customer service window: confirmations, reminders, re-engagement.

You can do all of this directly on Meta's Cloud API, or through a business solution provider that adds a dashboard and usually a fee. With an integrator or your own developers, going direct means paying only Meta's per-message rates, which we break down in WhatsApp Business API pricing.

The webhook, done properly

Two checks, both simple, both commonly skipped:

• Verification, once. When you register the webhook, Meta sends a GET request with a hub.challenge and the verify token you chose. Your service checks the token and echoes the challenge back.
• A signature, on every delivery. Each POST carries an X-Hub-Signature-256 header: an HMAC-SHA256 of the body, keyed with your app secret. Check it before trusting anything in the payload. Without it, anyone who finds your webhook URL can post fake orders.

Then answer fast and do the work afterwards. Meta retries deliveries that aren't acknowledged, so slow processing turns into duplicate messages. Key everything on the WhatsApp message ID so a redelivery is recognized, not processed twice.

Message types and their limits

What we hit in production, in our WhatsApp service on Graph API v21.0:

• Buttons: up to 3 per message, titles up to 20 characters. Good for "Approve / Return / Call me".
• Lists: up to 10 items per section, titles up to 24 characters, descriptions up to 72. More than 10 choices means a different design, not a longer list.
• No media with buttons. An interactive message carries its own text and cannot also carry an image or a document. Send the PDF first, then the buttons.
• Media is uploaded, then referenced. You upload the file to Meta, get a media ID, and send a message pointing to it. Give documents a filename, or the customer sees an opaque ID instead of "Quotation 1042.pdf".
• Read receipts are yours to send. Mark incoming messages as read so the customer sees the blue ticks, and knows someone is on it.

Voice notes: the part customers actually use

In many markets the order doesn't come as text. It comes as a voice note, sometimes several, sometimes in two languages.

For Qortex, a retail platform in the UAE, we built the engine that turns WhatsApp voice notes from shops into structured orders. Whisper transcribes the audio, in Arabic, English or both; running transcriptions in parallel per conversation made them 30 to 47% faster. The hard part wasn't transcription: it was ordering. Customers send a voice note, then a text correction, then another note. A queue processes each conversation's messages in strict sequence and merges them into one order, matched against that merchant's own catalog. The case study has the details.

For Casa Europa, quotation approvals happen on a dedicated WhatsApp number: an approver receives the quotation PDF, then approves or returns it by button or by voice note. A transcript is never trusted directly: it is read back to the approver for confirmation before anything is acted on. And the WhatsApp service holds no authorization logic of its own: the sender's phone number is resolved by the quotation platform, which applies its own roles.

That last point generalizes. The WhatsApp layer receives, normalizes and replies; your business system decides who may do what. Keeping the two apart is what lets one WhatsApp integration serve several workflows safely.

Connecting it to your CRM or ERP

The same pattern we use for order entry automation:

1. Normalize every message, text, voice, image or button press, into one internal format.
2. Understand it: transcribe, extract who, what and how many.
3. Match it to your records: the customer from the phone number, the products from their catalog or their usual orders.
4. Ask when something is ambiguous, with buttons where possible, instead of guessing.
5. Confirm and write: read back what will be recorded, wait for the yes, then create the order or update the CRM.

Questions to ask before you build

• Which number, and who replies today? Moving a number customers already use is where most of the value is.
• What arrives: text, voice, photos, documents? Voice changes the project.
• What must happen outside 24 hours? Each of those needs an approved template, and is billed as one.
• Who may approve what? Keep that in your business system, not in the WhatsApp layer.
• What does a wrong record cost you? It decides where a person confirms before anything is written.

Our published prices for a first integration flow in production are $5,000 to $18,000, with maintenance from about $470 a month. More on API integration services.

Related: WhatsApp Business API pricing, Transcribing mixed Arabic-English voice messages, and From WhatsApp to Salesforce, a reference architecture.