Keeping your WhatsApp integrations working
Nothing errors. Nothing alerts. The flow just stops doing the thing it used to do, and you find out from a customer.
Integrations almost never fail loudly. There is no red banner, no email, and usually no error a merchant would see. The flow simply stops producing the outcome it used to, and the gap between that happening and somebody noticing is frequently measured in weeks.
This page is the list of what actually breaks, what each failure looks like from outside, and the check that catches them.
The five failures
| What broke | How it looks | Fix |
|---|---|---|
| A Shopify permission is missing | Order flows run, one step silently does nothing | Reconnect the store |
| A spreadsheet column was renamed | The lookup returns nothing; the flow takes the failure path | Rename it back, or update the mapping |
| An API token expired or was rotated | Every lookup fails; customers get the fallback | Update the token in the block |
| A colleague's Google account was closed | Sheets steps stop working for everyone | Reconnect under an account that will outlast people |
| A template was paused or rejected | Messages stop arriving for one specific flow | Fix and resubmit the template |
Note how many of these are caused by somebody doing something entirely reasonable in another system. That is the nature of the problem — nothing went wrong here, and so nothing here reports it.
Where to look first
Each automation records its runs and where each one stopped. That is the diagnostic, and it is much better than the inbox, because the inbox shows you what was sent rather than what failed to send.
Three questions answer most incidents:
- Is the flow running at all? No runs means a trigger problem — the store disconnected, the event stopped arriving, the rule was unpublished.
- Is it running and stopping at a step? That names the broken integration directly.
- Is it completing but sending nothing? Usually a template problem, or an empty variable being guarded correctly.
The quarterly check
Fifteen minutes, four times a year, and it catches every row in the table above:
- Place a test order on your own store and follow it through confirmation and fulfilment.
- Run one lookup of each kind — a sheet, and your own API if you have one.
- Check a flow writes where it should — a row appended, a field updated.
- Open your template list and look for anything paused or rejected.
- Check who owns each connection — the Google account, the API token, the phone numbers in internal alerts.
Step five is the one that prevents the failure nobody anticipates: an integration running on the account of somebody who left in March.
Make failures visible while they happen
Better than any periodic check is a flow that tells you when something goes wrong. Both the lookup step and the spreadsheet step branch on failure, so the failure path can do more than apologise to the customer.
Wire it to an internal note and an alert, and you find out the first time it happens rather than the fiftieth. The mechanics are in internal notes and team alerts from a flow, and the alert needs an approved template because your colleague has no open conversation window with your business number, per Meta's sending messages documentation.
Two integration-specific gotchas
Reconnecting Shopify does not backfill. Events that happened while the store was disconnected are gone — there is no queue waiting to catch up. If you disconnect deliberately, treat the orders from that window as ones your team handles by hand.
An unexplained 401 from the Claude connection is usually the
address. The connection must be configured against
https://www.convofly.ai/mcp. Using the bare domain redirects to the
www host, and most clients drop the authorisation header across a
redirect between hosts — which produces a failure that looks exactly like a bad
token, and sends people off rotating credentials that were fine. The setup is in
connecting Claude
to your WhatsApp account.
Ownership, written down
The single cheapest thing you can do is keep a short list: each integration, what it does, whose account or credential it runs on, and who to ask when it breaks.
| Integration | Runs on | Owner |
|---|---|---|
| Shopify | The store connection | Whoever administers the store |
| Google Sheets | A specific Google account | Should be a shared account, not a person |
| Your own API | A token | Whoever maintains the endpoint |
| Claude connection | An admin token | An admin, reviewed when people leave |
Four rows for most businesses. It takes ten minutes to write and it is the document you will want at the exact moment nobody has time to reconstruct it.
Frequently asked
Will I get an email when something breaks?
Not automatically. Build the alert into the flow's failure path — that is the mechanism, and it is more reliable than a generic notification because it fires on the thing you care about.
How do I know if a template was paused?
Your template list shows the status. A flow whose messages stopped arriving with no other symptom is usually this.
Is reconnecting risky?
No, and it is the correct fix for a missing permission. It just does not recover what was missed.
What if a flow worked in testing and not in production?
Frequently a variable that is populated in your test order and empty in a real one — manual fulfilment with no tracking number is the classic case. See connecting Shopify to WhatsApp.
Why nothing tells you
Worth understanding, because it explains the whole shape of the problem. Every one of these failures is, from the software's point of view, a legitimate outcome. A lookup that finds no row is not an error — customers do sometimes give you an order number that does not exist. A missing permission means a call is simply not made. A paused template means a send is refused by Meta rather than by us.
So the system does the correct thing with each, which is to take the failure path you built. If that path apologises to the customer and stops, everything is working exactly as designed and nobody upstream learns anything.
That is why the fix is not better error reporting in the abstract. It is that your failure paths should tell you as well as the customer.
A worked failure, start to finish
- Symptom: customers say they are not getting tracking messages.
- Check the flow's runs. They exist, so the event is arriving.
- Find where they stop. At the send step.
- Check the template. Paused, following a quality drop.
- Fix and resubmit, and in the meantime tell the team so they can send manually.
Five steps, and the important one is the second: distinguishing "not running" from "running and failing" cuts the search space in half immediately.
What to check after any change elsewhere
| Somebody changed | Check |
|---|---|
| Your Shopify app permissions | Order and fulfilment flows, end to end |
| A spreadsheet's headers | Every flow that reads or writes that sheet |
| An API credential | Every block that carries a token |
| A team member's accounts | Google connections and alert phone numbers |
| A template's wording | That it is still approved and still matches the variables the flow sends |
The last row catches a specific and annoying case: editing a template can change how many variables it expects, and a flow still sending the old number will fail on every send. Free-form replies inside the 24-hour window remain free under Meta's pricing documentation, but a template that will not send costs you the conversation entirely.
The 4 habits that prevent most of this
- Connections owned by shared accounts, not individuals.
- Failure paths that alert somebody, not only the customer.
- A quarterly test order, diarised.
- A one-page list of what runs on what.
None of them are technical, and together they turn a category of silent failure into something you find out about the same week.
A monitoring flow you can build in 20 minutes
The most reliable way to know an integration still works is to exercise it on a schedule and be told when it does not. A small flow can do exactly that:
- Trigger it yourself — a keyword only your team knows, sent from a team phone.
- Run one lookup against your endpoint or your sheet, with a value you know exists.
- On success, reply with what came back so you can see it is current.
- On failure, add an internal note and alert whoever maintains it.
- Do it weekly — it takes 10 seconds and it replaces a quarterly audit for that one integration.
It is not sophisticated monitoring. It is a way of finding out on a Monday morning rather than from a customer, which is most of the value.
What to do the moment you find a break
- Tell the team first, so they can handle by hand while it is down.
- Fix the cause, not the symptom — a re-entered token that will expire again next quarter is a repeat visit.
- Check what was missed, especially with Shopify, where nothing is backfilled.
- Add the alert you did not have, so the next occurrence is noticed immediately.
The third is the one that protects customers. An integration that was down for three days means orders whose messages never went out, and those customers are better served by a manual message than by nothing.