How to connect WhatsApp to your existing CRM (API and webhooks)

Every WhatsApp-to-CRM project I have been asked to look at started with the same sentence: "we just need the chats to show up in the CRM." It sounds like one job. It is two, they run in opposite directions, and almost all the pain lives in one of them.

I build BNex, a WhatsApp Business Platform product, and the integration layer is the part customers ask about most. This is the plain version: what the two directions are, what each one costs you in effort, and the order I would build them in.

What "connecting WhatsApp to a CRM" really means

There are two data flows, and they fail for different reasons:

• Inbound (webhooks). Meta posts every incoming message, and every delivery status, to a URL you own. Your job is to receive that POST, answer it fast, and write the payload into the CRM against the right contact.
• Outbound (REST calls). Your CRM decides a message should go out, so it calls the WhatsApp API with a template or a free-form reply, and stores the returned message ID so it can match the delivery status coming back on the webhook.

If you only build the first, you have a chat viewer. If you only build the second, you have a notification cannon with no replies attached. You need both, and they share one piece of state: the message ID.

The inbound direction: the webhook is where integrations break

Meta delivers to your endpoint by HTTP POST. Two things have to be true before anything else works:

1. The verification handshake. While registering the callback URL you answer one GET request by echoing back the hub.challenge value, and you check the hub.verify_token matches the token you set. Skip the check and you have published an open endpoint.
2. A 200, immediately. Meta expects a fast success response. If your handler does the CRM write first and replies after, slow CRM calls become webhook retries and duplicate records. Accept the payload, return 200, then process asynchronously.

Beyond those, the durable rules are boring but they are what separate a demo from something you can run for a year:

• Deduplicate on the WhatsApp message ID. Retries are normal. Writing on every delivery is what produces three copies of one customer reply.
• Store the timestamp as sent, not as received. Delivery lag is real, and a CRM timeline built on receive time will read out of order during a backlog.
• Handle status events, not only messages. sent, delivered, read and failed arrive on the same webhook. A failed send with a reason is the most useful signal you get; a system that drops it looks like it works.
• Keep the raw payload for a while. When a message lands against the wrong contact, the raw JSON is the only thing that tells you why.

Where this usually goes wrong is not Meta. It is the CRM side: a contact that does not exist yet, a phone number stored as +91 98... in one table and 9198... in another, or a conversation that arrives before the record it belongs to. Normalise phone numbers to a single format at the edge, and create-or-match the contact before you write the message.

The outbound direction: the 24-hour window decides the design

Outbound is easier to call and harder to design, because WhatsApp does not work like email. There is a customer service window: after a customer messages you, you can reply with free-form text for a period of time. Outside that window, business-initiated messages must use an approved template.

That single rule shapes the whole integration:

• Inside the window, treat it like chat. Your support agent's reply goes out as a free-form message with a thread carried by a reply context.
• Outside the window, your CRM needs a template, not a paragraph. The trigger ("invoice overdue by 3 days") maps to an approved template whose variables get filled from the CRM record.
• Message status is the CRM field nobody builds. "Reminder sent" is not the useful state. "Reminder delivered, not read" is, because it tells your team whether to pick up the phone.

The mechanics of the window are worth reading once in full: the automation and 24-hour window guide covers what is allowed when, and the Cloud API setup guide walks the Meta side end to end, including the webhook verification handshake. If your CRM tool vendors a WhatsApp integration, most of what it does is exactly this: it holds one webhook endpoint and maps payload fields into its own lead and deal tables.

What you actually need before writing code

The last two rows are the ones teams skip, and they are the two that generate duplicate records and support tickets in month two.

Build it in this order

1. Webhook endpoint live and verified, logging raw payloads, writing nothing.
2. Inbound messages matched to contacts, deduplicated by message ID.
3. Outbound replies inside the window, using the same stored message ID to attach status.
4. One template, one real trigger, with the failure path tested by forcing an error.
5. Everything else.

Skipping step 4 is common and expensive: the first template rejection teaches you more about your integration than any amount of local testing. The reasons templates get refused are predictable, and the rejection post lists them.

Where an off-the-shelf platform fits

You have two honest options. Build the integration yourself against the Cloud API, or use a platform that already exposes the two directions as product features. Both are legitimate; they cost different things.

If you build it yourself, budget for the maintenance no one mentions: token rotation, template re-approval when Meta's rules shift, retry handling, and a queue for outbound sends so a CRM bulk action does not hammer the API. If you use a platform, check three things before you commit:

• Does it expose outbound API access, or only its own interface? A tool that cannot be called by your CRM turns your CRM into a second inbox.
• Does it deliver inbound messages to your endpoint with the raw payload, or only into its own database?
• Who holds the business account? The ownership questions decide what happens on the day you want to leave.

BNex sits in that second category, and its integration surface is a REST API plus webhooks, which is the same shape as the DIY route except the sender, template queue and inbox are already built. Whether that is worth it depends on your team: a two-person startup with a developer will often prefer their own glue; a support team of ten without one usually will not.

A note on the unofficial route

If you are looking at a cheap library that drives WhatsApp through a QR session rather than an API, the integration question answers itself: there is no documented webhook and no stable contract, because the whole thing is a reverse-engineered client. It is worth understanding why before you build on it, which is what the unofficial API post covers. Whatever you build, do not build it on a stack that can be logged out.

The short version

Inbound is a webhook that must answer instantly; outbound is an API call governed by the customer service window; and message IDs are the thread that ties them together. Get those three right and the rest of the integration is field mapping. Get the webhook wrong and no amount of CRM configuration will hide it.

Want a second pair of eyes on your integration plan before you build it? Message me on WhatsApp: https://wa.me/917358722745. I will tell you honestly whether you need a platform or just a weekend of glue code.

Related Reading