Connecting WhatsApp Business API to your CRM

Connecting WhatsApp to a CRM is technically simple: messages arrive by webhook, you send by API call, and both are well documented. The hard part is deciding what a conversation belongs to. A phone number is not a customer record, one number often covers several people, and the same person may hold three numbers. Get that mapping wrong and you build a system that files every conversation in the wrong place.

Almost every stalled integration we have seen stalled there, not on the API.

What are you actually connecting?

Four flows, and it is worth naming them separately because they have different requirements.

Flow	Direction	Where the difficulty is
Inbound messages into the CRM	WhatsApp → CRM	Matching the number to a record
Outbound from the CRM	CRM → WhatsApp	Template approval and the 24-hour window
System-triggered notifications	Your systems → WhatsApp	Deciding what genuinely warrants a message
Conversation history on the record	Both	Storage, retention and who may read it

Most projects scope the first two and discover the fourth halfway through, usually when someone asks whether the sales team should be able to read support conversations.

Why is matching the number so difficult?

Because in business, phone numbers do not map cleanly to people.

One number, several people. A dealer counter number is used by whoever is standing there. The conversation belongs to the dealer account, not to an individual.

One person, several numbers. A personal number, a business number, and the one they gave you two years ago. Without merging, you build three histories of one relationship.

Unknown numbers. Someone messages who is not in the CRM at all. Do you create a record, hold it in a queue, or discard it? Creating one for every enquiry fills the CRM with junk; discarding loses genuine leads.

Formatting. Numbers stored with country codes, without, with spaces, with a leading zero. A match that fails on formatting looks identical to a genuinely new contact.

Normalise every number to a single format on the way in and on the way out. It sounds trivial and it is the most common cause of duplicate records in these integrations.

What does the 24-hour window change?

It constrains outbound messaging in a way most CRM workflows are not designed for.

Within 24 hours of a customer messaging you, you can send freely. Outside it, you must use a template approved in advance. So a salesperson typing a follow-up three days later cannot simply send it — the system has to know which state the conversation is in and offer the right option.

The integration should show that state clearly, not let someone compose a message that will fail on send. It should also cover the common cases with templates: the follow-up, the quotation, the reminder. Discovering at the point of sending that no suitable template exists is a bad experience that teaches people to use their personal WhatsApp instead — which defeats the entire project.

Note also that from 1 October 2026 messages inside that window become chargeable, having been free. Volume decisions taken during integration now have a cost attached — see the billing change.

What should trigger a message automatically?

Fewer things than the enthusiasm of a new integration suggests.

The test: would the customer have wanted to know this if they had to be told by a person? Order dispatched, yes. Payment received, yes. Stage moved from “qualified” to “proposal” in your pipeline, no — that is your process, not their news.

Automated messaging is where WhatsApp integrations most often damage the relationship they were meant to improve. Every message you send that the recipient did not need moves them closer to blocking you, and a block is far more costly than the message was worth.

What questions decide the design?

• What does a conversation attach to — a contact, an account, or a deal? Decide before building.
• Who may read it? Support conversations often contain things a sales team should not see.
• What happens to an unknown number? Queue, auto-create, or ignore.
• Where is consent recorded, and does the outbound flow check it before sending?
• How long are conversations retained? This is personal data under DPDP and needs a stated period.
• What happens when a message fails? Someone must see it, or you will silently stop reaching a customer.

The fourth is the one skipped most often. If your outbound flow does not check consent before sending, your compliance depends on every user remembering — which is not a control.

How should you sequence the build?

Inbound first. Get messages arriving, matched and visible against the right record before building anything outbound. It is lower risk — nothing is sent to a customer — and it surfaces every matching problem while the cost of fixing them is low.

Then outbound replies within the window, then templates, then automated triggers last. Teams that start with automated notifications usually end up rebuilding, because the matching underneath was never tested.

This is the kind of work we do under system integration, and the pattern holds well beyond WhatsApp.

Common questions

Can we connect WhatsApp to any CRM?

If it has an API or supports webhooks, yes. Some have ready-made connectors, which are quicker but usually make their own decisions about record matching — check those decisions match how your business is structured before adopting one.

Should conversations be stored in the CRM or the messaging platform?

A reference in the CRM with the full history in the messaging platform usually works better than duplicating everything. Duplication creates two records that diverge and two places to honour a deletion request from.

How do we handle a customer asking to be forgotten?

Decide during design, not when the request arrives. You need to know every place a conversation is stored — CRM, messaging platform, provider, backups — and have a route to remove it from each.

Can several agents use one number without conflict?

Yes, and that is one of the main reasons to use the API. You need assignment rules so two people do not answer the same conversation, which is an interface problem rather than an integration one.

More on this: Business App vs API and why your template was rejected. See also CRM systems.