WhatsApp error 131026: the three causes Meta publishes

What does WhatsApp error 131026 mean, and what has Meta actually told you?

Meta's label for 131026 is "Unable to deliver message", and the cause list it publishes underneath that label has exactly three entries: the number is not a WhatsApp number, the person has not accepted the current Terms of Service, or their WhatsApp client is older than a set of builds Meta names. Everything else commonly attributed to this code — that the recipient blocked you, that their country is restricted, that they opted out of your marketing — is not in that entry.

Here is the entry in full, read from the page Meta serves today:

"Unable to deliver message. Reasons can include: The recipient phone number is not a WhatsApp phone number. Recipient has not accepted the new Terms of Service and Privacy Policy. Recipient using an old WhatsApp version; must use the following WhatsApp version or greater: Android: 2.21.15.15 SMBA: 2.21.15.15 iOS: 2.21.170.4 SMBI: 2.21.170.4 KaiOS: 2.2130.10 Web: 2.2132.6" (Meta — WhatsApp Cloud API error codes)

Two things about that page are worth noting. Meta has moved the error reference to /documentation/business-messaging/whatsapp/support/error-codes, and 131026 sits under the heading "Other errors" rather than any delivery-specific grouping. And Meta does not call this error "Message Undeliverable" anywhere on the current page. That phrase has a life of its own regardless, but it is not Meta's wording, which is worth noticing about any page that uses it as a title.

The practical consequence of a three-item list is that 131026 is a narrower signal than it feels. That is not the same as saying Meta tells you everything. On a separate page, Meta publishes a longer list of reasons a message does not arrive and states plainly that it withholds which one applied:

"…we will not disclose the underlying cause of the error, because of privacy and policy reasons." (Meta — Cloud API support)

So two things are true at once, and most pages about this code get one of them wrong. Meta does keep non-delivery causes to itself. But the error value you were handed is not where it hides them: 131026's entry is a short, specific, boring list, and the code acquires its reputation for mystery because operators reach for it to explain failures Meta files under other codes, or under no code at all.

• What does WhatsApp error 131026 mean, and what has Meta actually told you?
• Which explanations for 131026 are documented under a different code?
• Which error code actually covers blocking, and which way does it run?
• Why is "ask them to update WhatsApp" a 2021 answer?
• Why did the send return 200 and the failure arrive later?
• Are you charged for a message that fails with 131026?
• Does 131026 mean Indian numbers reject authentication templates?
• What should you actually do when a 131026 arrives?
• Which of these failures can a platform prevent for you?

Which explanations for 131026 are documented under a different code?

Most of the causes attributed to 131026 are real WhatsApp behaviours. They simply arrive as other numbers, each carrying its own remedy. If you are reading 131026 and thinking about opt-outs or closed windows, you are debugging the wrong entry.

Each of the first four is quotable. 131047 is defined as "More than 24 hours have passed since the recipient last replied to the sender number." 131050 reads "Unable to deliver the message. This recipient has chosen to stop receiving marketing messages on WhatsApp from your business." And 131049 is the terse one: "This message was not delivered to maintain healthy ecosystem engagement." (Meta — WhatsApp Cloud API error codes)

The mechanics behind that last one are published separately, under per-user marketing limits:

"WhatsApp may limit the number of marketing template messages a WhatsApp user receives from any business in a given period of time when they are less likely to be receptive and engage with those messages." (Meta — Per-user marketing template message limits)

That is a per-recipient cap counted across every business messaging that person, which is why it feels arbitrary from inside one account. The full behaviour is covered in what error 131049 actually counts. The point here is that it is a different number with a different fix, and treating it as a flavour of 131026 sends you looking at contact data when the problem is send volume.

Which error code actually covers blocking, and which way does it run?

There is no WhatsApp Business Platform error code for a user blocking a business. The words block, blocked and blocking do not appear in the 131026 entry at all, and no other published Cloud API error describes that event.

What does exist is 130403, and it runs the opposite way:

"Unable to deliver the message. This business has blocked the end user on WhatsApp" (Meta — WhatsApp Cloud API error codes)

with the solution given as "Do not retry. Unblock the WhatsApp user to resume sending messages to them." That is the business blocking the person, not the person blocking the business.

So where does the blocking folklore come from? From Meta, in a place almost nobody links. Under the heading "Message not delivered", the Cloud API support page lists causes that never appear in the error table at all, this one included:

"The customer has blocked the business phone number, or another business phone number owned by the business." (Meta — Cloud API support)

It sits alongside "The customer is in a restricted or sanctioned country" and "The WhatsApp user did not come online during the 30-day window where we hold messages for offline customers." The troubleshooting list under it is nearly word for word the solution column of the 131026 entry, with one extra instruction: ask the customer to "confirm that none of your WhatsApp Business phone numbers are in their list of blocked numbers".

Hold those two pages side by side and the precise position falls out. Blocking is documented as a reason a message does not arrive. It is not documented as an error code, it is not named in the 131026 entry, and Meta says it will not tell you which of those reasons applied. So an integration that renders 131026 as "this contact blocked you" is converting a maybe into a certainty, on a code whose own published causes say nothing about blocking.

Why is "ask them to update WhatsApp" a 2021 answer?

Read the version floor in Meta's own text again: Android 2.21.15.15, iOS 2.21.170.4, KaiOS 2.2130.10, Web 2.2132.6. Meta does not date those builds on the page, and those are still the numbers it names today. WhatsApp's release numbering puts the 2.21 series in 2021, which makes the floor in this entry roughly five years old.

That matters because the stale-client cause turns most easily into a support script: ask the customer to update WhatsApp. Against a floor that old, a handset failing the check has not updated the app in years. Possible, but not where a triage starts. Meta's own remedies are all out-of-band, and the first is not about versions at all:

"Confirm that they can actually send a message to your WhatsApp Business phone number." (Meta — WhatsApp Cloud API error codes)

That single instruction covers the first cause too. If the customer cannot message you from the number you hold for them, it is probably not the WhatsApp number they use: a digit wrong in a CRM field, a landline captured by a web form, a work number that never had an account against it. Check that first. It is the cause that is both common and fixable in your own database.

The version instruction sits third for a reason:

"Update to the latest version of the WhatsApp client." (Meta — WhatsApp Cloud API error codes)

Keep it in the script. Stop leading with it.

Why did the send return 200 and the failure arrive later?

This is the integration mistake that makes 131026 hard to see at all. It is not, in the ordinary case, an HTTP error response from your POST to the messages endpoint. Meta is explicit that errors take more than one route:

"Cloud API errors are returned either synchronously as a Graph API response, asynchronously via Webhook, or sometimes through both methods." (Meta — WhatsApp Cloud API error codes)

For an outbound message that Meta accepted and then could not deliver, the asynchronous route is the one that fires. The webhook reference places it precisely:

"Outgoing message errors appear in the statuses array (entry.changes.value.statuses.errors)." (Meta — Webhooks components reference)

And Meta adds a timing warning that matters for anything reconciling sends automatically:

"If you send a message that fails (status set to failed), there could be a minor delay before you receive the webhook, so you may wish to build in a small buffer before assuming the message was dropped." (Meta — Send messages)

So the sequence is: your call returns 200 with a message id, your row is written as sent, and some seconds later a failed status arrives carrying 131026 in its errors array. A pipeline that records the send result and never reconciles the status webhook will show that message as sent indefinitely.

That is not theoretical. A public issue against an open-source inbox reports the two signals disagreeing on screen and titles the problem exactly that way: "WhatsApp Cloud: message shows delivered in UI but DB remains sent; external_error 131026 stored simultaneously" (chatwoot issue #13377). The consequence is the part to take away: agents trust the delivered icon while Meta has reported the message undeliverable.

Any shared inbox, WabaCRM's included, is rendering the last status webhook it received for that message. The tick is only as honest as the reconciliation behind it, which is why a message that stalls on sent with no later status deserves more suspicion than one that arrives labelled failed. A broader version of that problem — everything looking connected while nothing lands — is covered in the dashboard says connected and nothing is sending.

Are you charged for a message that fails with 131026?

Meta says nothing about 131026 specifically in its pricing documentation, and there is no exemption written against that code. What Meta does state, as a general rule, is the condition under which a template charge applies at all:

"You are only charged when a template message is delivered ("type":"template")." (Meta — Pricing on the WhatsApp Business Platform)

Draw the inference rather than trusting a vendor page that asserts a 131026-shaped exemption: a message that failed is by definition not a delivered template message. That is as far as Meta's text takes you, and the way to confirm it for your own account is to reconcile Meta's billing figures against your send records, as in reading what Meta actually charged you.

A second supposed cost is worth checking rather than repeating. Vendor pages warn that failed sends burn your messaging limit. Meta's definition of that limit is keyed to delivery:

"Messaging limits are the maximum number of unique WhatsApp user phone numbers your business can deliver messages to, outside of a customer service window, within a moving 24-hour period." (Meta — Messaging limits)

A message that failed with 131026 was not delivered, so on Meta's own wording it should not consume the limit. Meta does not address the failed-send case either way, so do not build a sending plan on that reading. What a failed send does cost is plainer and needs no interpretation: a retry loop against a number with no WhatsApp account behind it buys nothing at any volume, adds failures to your own delivery statistics, and postpones the only fix that works, which is correcting the number or retiring it.

Does 131026 mean Indian numbers reject authentication templates?

A claim circulates that authentication templates sent to +91 numbers always fail with 131026. I went looking for it in Meta's documentation and could not find it.

Where India does appear is on the rate card, as a billing scope:

"The following countries have authentication-international rates: Egypt, India, Indonesia, Malaysia, Nigeria, Pakistan, Saudi Arabia, South Africa, United Arab Emirates." (Meta — Authentication-international rates)

That is a price band, not a delivery rule. The authentication templates page itself carries no mention of India, of +91, or of any country-specific delivery restriction tied to an error code.

The nearest real behaviour is about devices rather than countries:

"Authentication messages that are sent to a user's linked devices are masked with a prompt instructing the user to view the message on their primary device." (Meta — Authentication templates)

Meta ties that masking to no error code. So the position here is the one this site takes on any unsourced figure: the claim was searched for at the primary source, it was not found, and it is not repeated. If Meta publishes a country-scoped delivery restriction later, it will be on those pages and not in a vendor blog post first.

What should you actually do when a 131026 arrives?

Four steps, in this order, because the cheap checks are also the likely ones.

1. Confirm you are reading 131026 and not a neighbour. Pull the code out of entry.changes.value.statuses.errors rather than out of a dashboard label. 131047, 131049, 131050 and 130403 all surface as "the message did not arrive" in a UI.
2. Check the number, not the customer. A stored number that is not the person's WhatsApp number is the first documented cause and the one you can test without contacting anyone: compare it against the number that last messaged you, and against your formatting rules for the country.
3. Ask out of band, once. Meta's own remedy is an email or a phone call asking the person to confirm they can message your business number, and to accept the latest Terms of Service. Meta's support page adds one more question for the same conversation: whether your number is in their blocked list. One attempt, not an automated sequence.
4. Stop the retries. Mark the contact as undeliverable in your own system and take them out of the next broadcast rather than letting a scheduler re-attempt them every cycle. Nothing in Meta's cause list changes because you tried again.

Only after all four would I treat the client version as the live theory, and even then the fix is the customer's.

Which of these failures can a platform prevent for you?

Honestly: none of the three documented causes. Whether a number has a WhatsApp account behind it, whether its owner accepted the current Terms of Service, and what app build they are running are all facts about someone else's phone. No software vendor can change any of them, and one telling you otherwise is describing a capability Meta does not expose.

What a platform can do is narrower and still worth having. It can surface the raw code and the raw errors array rather than a paraphrase, so the triage table above is usable at all. It can reconcile the status webhook against the send so a row does not sit on sent forever. It can stop feeding an undeliverable contact into every subsequent campaign, and keep import validation tight enough that a landline never reaches a send queue. The shared inbox guide covers how those statuses land in front of a team rather than in a log nobody reads.

That is the whole honest offer on this error. The code is a short, published list; most of what gets attributed to it belongs to other codes; and the remainder belongs to a page where Meta says outright that it will not tell you which cause applied.

Every Meta quotation on this page was read from Meta's own documentation on 11 September 2026. Meta changes that documentation without notice; the linked pages are authoritative and this one is not.