🔌 Integrations

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 brokeHow it looksFix
A Shopify permission is missingOrder flows run, one step silently does nothingReconnect the store
A spreadsheet column was renamedThe lookup returns nothing; the flow takes the failure pathRename it back, or update the mapping
An API token expired or was rotatedEvery lookup fails; customers get the fallbackUpdate the token in the block
A colleague's Google account was closedSheets steps stop working for everyoneReconnect under an account that will outlast people
A template was paused or rejectedMessages stop arriving for one specific flowFix 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:

  1. Is the flow running at all? No runs means a trigger problem — the store disconnected, the event stopped arriving, the rule was unpublished.
  2. Is it running and stopping at a step? That names the broken integration directly.
  3. 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:

  1. Place a test order on your own store and follow it through confirmation and fulfilment.
  2. Run one lookup of each kind — a sheet, and your own API if you have one.
  3. Check a flow writes where it should — a row appended, a field updated.
  4. Open your template list and look for anything paused or rejected.
  5. 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.

IntegrationRuns onOwner
ShopifyThe store connectionWhoever administers the store
Google SheetsA specific Google accountShould be a shared account, not a person
Your own APIA tokenWhoever maintains the endpoint
Claude connectionAn admin tokenAn 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

  1. Symptom: customers say they are not getting tracking messages.
  2. Check the flow's runs. They exist, so the event is arriving.
  3. Find where they stop. At the send step.
  4. Check the template. Paused, following a quality drop.
  5. 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 changedCheck
Your Shopify app permissionsOrder and fulfilment flows, end to end
A spreadsheet's headersEvery flow that reads or writes that sheet
An API credentialEvery block that carries a token
A team member's accountsGoogle connections and alert phone numbers
A template's wordingThat 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

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:

  1. Trigger it yourself — a keyword only your team knows, sent from a team phone.
  2. Run one lookup against your endpoint or your sheet, with a value you know exists.
  3. On success, reply with what came back so you can see it is current.
  4. On failure, add an internal note and alert whoever maintains it.
  5. 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

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.

Need help? Message us