Connecting a CRM or ERP to WhatsApp
Two mechanisms, one developer task each, and a clear answer about what is not possible.
There is no one-click connector for your CRM or ERP, and it would be dishonest to imply otherwise. What exists are two general mechanisms that between them cover almost everything people mean by "integrate our system with WhatsApp".
Both need a developer once. Neither needs one afterwards.
The two directions
| Their system starts a flow | A flow reads or writes their system | |
|---|---|---|
| Mechanism | External event API | Call External API step |
| Who calls whom | Your software posts to us | A flow calls your endpoint |
| Good for | "When X happens, message the customer" | "When they ask, look it up" |
| Trigger | The event itself | The customer's message |
| Work needed | A POST from your system | An endpoint we can reach |
Most real integrations use both. An event starts the conversation, and a lookup inside it fetches the detail the event did not carry.
Which one you need
Answer one question: what makes the message happen?
- Something happening in your system — a job status changing, an invoice going overdue, a delivery being booked. That is the external event route.
- The customer asking — "where is my order", "what is my balance", "when is my appointment". That is the lookup route.
Getting this the wrong way round is the most common design mistake, and it shows up as a flow that never fires because it was waiting for a message the customer had no reason to send.
What the external event route actually involves
Your system sends a small piece of data — who the customer is and what happened — and a flow whose trigger matches that event name starts running. Everything after that is built in the visual editor by whoever normally builds your flows.
The developer part is one HTTP call from your software. That is the whole scope, and it is worth being specific about when you brief somebody, because "integrate WhatsApp" sounds like a project and this is not one. The detail is in starting a flow from your own system.
What the lookup route involves
An endpoint that takes an identifier and returns some fields. The flow calls it mid-conversation, saves what comes back into contact fields, and uses those in the next message.
Two things to specify up front: what happens when nothing is found, and how fast it responds. Both are decisions rather than details — a customer waiting in a chat notices a slow lookup, and "not found" needs to be a designed path rather than an accident. See calling your own system from a flow.
When your CRM has no API
Then neither route is available, and the honest options narrow considerably:
- Export to a Google Sheet on a schedule, and have flows read the sheet. Crude, and it works for anything that does not need to be up to the second.
- Use a middleware tool your team already pays for, if it can talk to both.
- Keep the two systems separate and accept that somebody copies the important things across.
The first is more useful than it sounds. A nightly export of customer statuses into a sheet gives your flows something to branch on without anybody writing code.
What "integrates with your CRM" usually means elsewhere
Worth knowing while you compare tools, because the phrase covers several very different things:
| Claim | What it often is |
|---|---|
| "Native CRM integration" | Sometimes real; frequently a contact sync and nothing more |
| "Works with 5,000 apps" | A third-party automation platform in the middle, billed separately |
| "Two-way sync" | Ask what fields, how often, and in which direction |
| "Open API" | True and useful, and the same developer task as here |
The test that cuts through it: ask what a flow can do because of the connection. If the answer is "start on an event" or "read a value", it is real.
What none of it changes
Meta's rules. An event from your ERP does not create permission to message somebody: reaching a customer outside the 24-hour customer service window still needs an approved template, per Meta's sending messages documentation and its template documentation.
Which has a practical consequence for planning. Any integration whose whole point is to notify customers about something needs its templates approved before the integration is worth switching on.
A sensible order of work
- Write down the exact event or lookup you want, in one sentence.
- Check whether a Google Sheet would do, because it needs no developer.
- Get the template approved, if the flow messages a cold chat.
- Build the flow with placeholder data so it can be reviewed before the integration exists.
- Then book the developer, with a scope of one HTTP call or one endpoint.
Doing it in that order means the developer's part is the last and smallest piece, rather than a project everything else waits on.
Frequently asked
Is there a Zapier-style connector?
The external event API is the general mechanism, and any tool that can make an HTTP request can use it.
Can a flow update my CRM?
Yes, if your CRM accepts a write over its API — that is the POST direction of the lookup step.
How much developer time is this?
Small, if the scope is written down. Large, if the brief is "integrate WhatsApp".
What about Shopify?
That one is one-click, and it is the exception rather than the pattern. See connecting Shopify to WhatsApp.
A brief your developer can act on
The difference between a quick task and a stalled project is almost entirely the brief. A usable one fits on half a page and answers 5 questions:
- What event, exactly? "Invoice moves to overdue", not "billing stuff".
- Which customer does it concern, and what identifies them — a phone number, in the format your other systems use.
- What data travels with it? Keep it to the 3 or 4 fields the message actually needs.
- What happens on failure? Retry, log, alert — decide, do not leave it to whoever writes the code.
- Who owns the credential and when does it get rotated?
Answer those and the work is genuinely small. Leave them open and every one of them becomes a meeting.
Two patterns that cover most businesses
| Pattern | What it looks like | Needs |
|---|---|---|
| Status notification | Your system posts a status change; a flow sends an approved template | One POST, one template |
| Self-service lookup | Customer asks; a flow calls your endpoint and answers | One endpoint, no template |
The second is cheaper in every sense — no template approval, no messaging cost, because the customer started the conversation and replies inside the 24-hour window are free and unlimited under Meta's pricing documentation.
Where you have a choice, prefer the lookup. Where the customer would not know to ask, you need the notification.
Scale, before you build
One question worth asking early: how many messages would this integration send on a busy day? Your messaging tier caps unique recipients per rolling 24 hours on the 250 → 2,000 → 10,000 → 100,000 → unlimited ladder in Meta's messaging limits documentation, and an integration that would exceed your tier is one you should know about before it is switched on rather than after.
Who does what, in a small business
| Task | Who | How long |
|---|---|---|
| Decide the event or lookup | You | Minutes, if you already know the problem |
| Submit the template | You | Minutes to submit, longer to approve |
| Build the flow | You | An afternoon, less with practice |
| The HTTP call or endpoint | A developer | Small — it is one call |
| Testing it together | Both | An hour, and worth doing properly |
Four of the five rows are yours. That ratio is the point of building the flow in a visual editor: the part that needs code is the smallest part, and it is the part with the clearest specification.
Starting smaller than you think
The first integration should be the one that solves a single recurring annoyance — one status, one lookup — rather than the complete picture. It proves the mechanism, it gives your developer a small piece of work with a visible result, and it teaches you what the second one should be.
Businesses that begin with a full data sync between two systems generally end up with neither the sync nor the simple thing they actually needed.
The short version
Two mechanisms: your system posts an event and a flow runs, or a flow calls your endpoint and uses the answer. Both are one small developer task. Write the brief down, get the template approved first if the flow messages a cold chat, and start with one recurring annoyance rather than a full sync.
And if your CRM has no API at all, a scheduled export into a Google Sheet that flows can read is a legitimate answer rather than a workaround — it needs nobody technical and it covers anything that does not have to be current to the minute.
What none of these routes do is create permission. The template rules, the opt-in rules and the 24-hour window apply to a message triggered by your ERP exactly as they apply to one somebody typed by hand.