WhatsApp error codes, translated for shop owners

A WhatsApp error code is Meta's reason for refusing to deliver one of your messages. Every code below means the customer got nothing — which is why these matter far more than their obscure numbering suggests.

Most references for these are written for developers. This one is written from your side: what the customer experienced, what caused it, and the fix.

The five you will actually meet

131047 — "message failed" on a reply

The most common one, and the least alarming. It means the 24-hour customer service window has closed. Meta's documentation is clear that the window opens when the user messages or calls you and resets each time they do — so if they have gone quiet for a day, free text is no longer allowed.

The fix is structural rather than technical: if a flow may run more than a day after the customer last wrote, it must send a template, not free text. A delay step of 1,440 minutes or more in a flow that then sends free text is this bug waiting to happen.

131049 — the one people misread

This means Meta chose not to deliver a marketing template. Two very different causes hide behind one code.

• Per-user marketing limits. An adaptive cap on how many marketing templates one person receives from all businesses combined. Meta's documentation publishes no number for it, and it does not apply in the EEA, UK, Japan or South Korea, or to messages sent inside an open window.
• A US number. US phone numbers cannot receive marketing templates at all. If every US recipient in a campaign fails and nobody else does, this is why — and there is nothing to fix.

Meta's instruction on 131049 is counter-intuitive and worth following: wait at least 24 hours before retrying. Retrying sooner risks further blocks for up to 24 hours. The instinct to resend immediately makes it worse.

132000 — the parameter count mismatch

Your template has, say, three placeholders, and the sending step supplied two. Meta rejects the whole message. The customer gets nothing and, unless you are watching, you will not notice.

We have hit this ourselves on a seeded rule whose template gained a variable after the rule was created, leaving it sending zero of them. The lesson: if you edit a template's variables, check every automation that sends it.

A related trap is a variable that resolves to an empty string. A contact field that was never filled in — because it was never defined under Settings → Contact Attributes — sends nothing where Meta expects something.

131026 — undeliverable

The number is not reachable on WhatsApp. Usually one of: the number is not registered on WhatsApp at all, it is formatted wrongly, or it is a landline. In cash-on-delivery markets, where the phone number comes from a checkout form typed by hand, this is a data-quality problem rather than a messaging one.

A common and fixable version is the same customer existing under two numbers — one saved with a leading zero, one in international format. Store the number the same way everywhere and the problem mostly disappears.

What Meta does when problems repeat

Errors are not penalties, but the behaviours behind them can be. Meta's policy enforcement documentation describes a graduated ladder: a warning, then blocks of 1 to 3 days on a message type, then 5, 7 or 30-day blocks on all messaging, then an indefinite account lock which can be appealed, and finally permanent removal. Named triggers include spam, template misclassification, restricted categories and excessive negative user feedback. Appeals go through Business Support Home and are typically decided in 24 to 48 hours.

A diagnostic order for "my automation didn't send"

1. Did the flow run at all? Check the automation's activity view. No run means a condition blocked it — usually a keyword that did not match.
2. Did it run and stop early? The activity view names the step that stopped it.
3. Did it send and fail? Now you are looking at an error code. Match it above.
4. Did it send successfully but the customer says nothing arrived? Check whether the template variables resolved to something — an empty variable produces 132000, and a wrong number produces 131026.

That order matters. Most reported "delivery failures" turn out to be step one: a flow that never ran because a keyword list missed the phrasing the customer used. Keyword triggers that actually match covers that.

What to check before you blame the platform

Three questions, in order. Is the number on WhatsApp? Is the window open, or is this a template? Do the template's variables match what the flow supplies? Those three account for the overwhelming majority of failures, and all three are things you can check yourself in under a minute.

The failure that produces no error at all

Worth stating separately, because it is the most common report we see and it is not an error code: the flow never ran. Nothing failed, because nothing was attempted.

Every automation has an activity view showing each run and which condition stopped it. A flow showing zero runs has a matching problem, not a delivery problem, and the usual culprit is a keyword list that does not contain the phrasing customers actually use — especially in markets where people write in transliterated script. See keyword triggers that actually match and handling Roman Urdu and Hinglish.

Reading a partial delivery

When some recipients get a message and others do not, the pattern tells you which system stopped it. Working through these in the wrong order wastes a day.

That last row causes needless investigation. Read counts are structurally undercounted because customers can turn read receipts off, so treat delivered as the number that means something.

Preventing the two most expensive ones

132000 — the parameter count mismatch — is entirely preventable, and it is expensive because the customer receives nothing while your dashboard reports a send. Two rules stop it:

1. When you edit a template's variables, check every automation that sends it. A template that gains a variable leaves existing flows supplying too few.
2. Make sure no variable can resolve empty. The classic case is a contact field that was never defined under Settings → Contact Attributes, so the save silently did nothing and the send supplies a blank. The other is a manual fulfilment with no tracking number. Put a fallback word in the template if a value can legitimately be missing.

131047 is prevented at design time rather than send time. Any flow with a delay of 1,440 minutes or more that then sends free text will hit it, because the window will have closed while it waited. Either shorten the delay or make that step a template.

A one-page triage

1. Did the flow run? Activity view. No runs means a condition blocked it, usually a keyword.
2. Did it stop part-way? The view names the step — often an unwired failure branch on a lookup.
3. Did it send and fail? Match the code in the table above.
4. Did it send and succeed, but nothing arrived? Check whether a variable resolved empty, and whether the number is really on WhatsApp.
5. Is the whole account affected? Check quality rating and any enforcement notice before touching the flow at all.

Working in that order matters, because most reported "delivery failures" turn out to be step one — and no amount of investigating templates will find a keyword list that never matched.