Connecting monday.com to WhatsApp: What Actually Has to Be Built

The request sounds like one thing - "make WhatsApp work with monday" - and it is really two separate projects with entirely different problems. Worth separating before pricing, because one is simple and the other is all the work.

The two directions

Outbound is days. Inbound is what determines whether the project succeeds.

Why a middleware service is required

You cannot connect monday directly to Meta, for the same reasons you cannot connect Priority directly: the payload shapes differ, authentication differs, phone numbers need normalising, and something has to hold the template mapping and the index.

The architecture is always three parts:

monday (webhook)
   →
Middleware service (mapping + index + queue)
   →
WhatsApp Cloud API

And in reverse, that same service receives Meta's webhook and writes back into monday through its API.

Outbound: templates, not free text

This is the design point that defeats requests. You are initiating - the customer has not written to you - so the 24-hour window is closed by definition. Free text will be rejected.

Which means: every notification type needs a pre-approved template, in every language. You cannot "send whatever is in the notes column". You can only substitute values into positional variables.

So map the template set before writing code - how many message types the board genuinely needs, and what the variables are in each. It is usually fewer than the client expects: three or four templates cover most processes.

What triggers the send

monday has webhooks on board changes. Two notes:

• Actually test a change made by an internal automation, not only a manual edit. They do not always behave identically, and this is something to verify on the real board rather than assume.
• Verify the webhook genuinely came from monday rather than relying on the URL being secret. A public endpoint that triggers messages to customers is a target.

And never call Meta inside the webhook. Write to a queue, respond immediately, and process separately - otherwise a slowdown at Meta becomes a failure on monday's side.

Inbound: here is all the work

The customer replies. Now you must work out which item the reply belongs to, and write it there.

The problem: WhatsApp identifies by number, monday does not

Meta sends the phone number. In monday, the number sits in a column somebody filled in by hand - 052-1234567, 0521234567, +972521234567, sometimes two in one cell.

Without normalisation, every reply looks like a new lead. And this is not a one-off glitch - it accumulates quietly until someone asks why one customer has three items.

The fix: your own index, not board scanning

This is the most important technical point in the article.

The temptation is to fetch every item and search for a match. Do not. As detailed in the monday API guide, the real limit is not calls per day but the per-minute complexity budget - and a query walking every board and every item is a multiplication that can exhaust it in a single request.

In a messaging channel that is especially bad: messages arrive in bursts, and precisely when ten customers reply at once - the moment it most needs to work - the budget runs out.

Instead: keep a small table on your side mapping normalised number → item and board id. Maintain it when an item is created or a number changes. Lookup becomes a local query, and monday is called only when you need to write.

What to write back - and what not to

The second temptation is pushing the whole conversation into a text column. Do not: the column becomes enormous, is not genuinely searchable, and holds personal data somewhere never designed for it.

What is worth writing to monday:

• Status - replied, awaiting, undelivered
• A timestamp of the last message
• A link to the full conversation where it is stored

The board is the team's working interface. The transcript belongs where it can be searched and retained properly.

A technical note: writing to monday columns requires double-encoding column values - build an object, serialise it, and place that string in the mutation. And each column type has a different shape. Do not guess - read an existing correctly configured item and copy the shape.

What must be in place

• Idempotency in both directions. Webhooks get redelivered; the same message is not sent twice and the same reply is not recorded twice.
• E.164 normalisation on both sides, storing the normalised form.
• An error queue a human sees. A customer reply that failed to reach the board is a lost lead.
• What happens on no match. A message from an unknown number should create an item on a dedicated board and flag it for review - not vanish, and not land on the wrong board.

Checklist

1. Map the template set before the code, and submit for approval early - it takes time.
2. Test on the real board how webhooks behave with internal automations.
3. Build a number-to-item index; do not scan boards.
4. Normalise to E.164 on both sides.
5. Write status and a link to monday, not the conversation.
6. Decide what happens with an unknown number.
7. Verify both monday's webhook and Meta's.