On this page
Error 131026 means WhatsApp simply could not deliver the message: the number may not be on WhatsApp at all, may have blocked your business, or may be running software that cannot receive it. It is the most common failure on any imported or purchased contact list, and it is not something a retry usually fixes.
Symptom
A recipient row on a broadcast, a sequence step, or a single inbox send shows Failed with an error naming that the message was undeliverable, matching Meta's own code 131026. There is no more specific reason in the response itself, whether the number has no WhatsApp account, the recipient blocked your business number, they are on an old WhatsApp client version that cannot render the message type you sent, or they have not accepted WhatsApp's current terms of service. On a large import or a broadcast to an older list, 131026 is typically the single most frequent failure reason, often outnumbering every other error combined.
Why it happens
WhatsApp's Cloud API returns 131026 for any of several distinct underlying conditions, and Meta deliberately does not disclose which one applied, since separating "not on WhatsApp" from "blocked you" would let a business infer who specifically blocked them, which Meta treats as private. The most common real-world cause by far is a phone number with no WhatsApp account at all, common on lists gathered from lead forms, purchased databases, or contacts imported from a system where a phone number was recorded but never verified as a WhatsApp number. The second most common cause is a genuine block, where a recipient who received unwanted messages previously blocked the sending number directly in their WhatsApp client, a state Meta's API does not surface any other way. Less commonly, an old WhatsApp app version cannot render a specific message type (an interactive button, a certain media format), or the recipient has not accepted WhatsApp's latest terms of service and cannot receive business messages until they do.
Fix
- Do not retry the same number immediately. None of the underlying causes are things that change within minutes or hours, so an immediate retry almost always fails again and wastes part of your daily messaging budget on an attempt very unlikely to succeed.
- Check the contact's profile for the number and source. Open the contact under Contacts and confirm the phone number was entered correctly, in the right country format, and did not have a digit transposed during import.
- Treat a high failure rate on a fresh list as a data-quality signal, not an account problem. If a large share of a newly imported list fails with 131026, the list itself, not your number or your account, is the issue; see importing contacts from CSV without errors for the checks that catch bad numbers before you send to them.
- Wait for a positive signal before trying that number again. The only reliable way to know a number that failed with 131026 has become reachable is for that contact to message your business first; there is no status check to poll for "is this number now on WhatsApp."
- For a number you suspect blocked you specifically, do not keep sending to it. Repeated attempts to a number that has blocked your business do nothing but burn quota and, if the recipient reports the repeated attempts, contribute to a worse spam signal on your number.
How VGraple CRM handles it automatically
A 131026 failure is recorded on the contact with the date it occurred, and future broadcasts and sequence steps check for this before attempting a send, so a contact who has already failed with 131026 is not repeatedly retried by scheduled campaigns without a reason to believe anything changed. The state clears automatically the moment that contact messages your business through any connected channel, since an inbound message is unambiguous proof the number is live and reachable, at which point they become eligible for outbound sends again like any other contact. Import previews, when adding a CSV of contacts, surface how many of the numbers being added have previously failed with 131026 so the decision to import them anyway is a deliberate one rather than a surprise discovered from the next broadcast's failure count.
Because 131026 is one of the codes Meta treats as a policy-adjacent failure a retry cannot fix, it sits alongside 131049, 131050 and 130472 in VGraple CRM's non-retryable classification, meaning "Retry failed" on a campaign will not re-attempt these rows; retrying them serves no purpose and, since Meta's account-level retry penalties took effect on 30 April 2026, repeatedly retrying a number that has already failed for a policy reason like this can count against the account rather than only wasting a send.
Example
A D2C store imports a 3,000-row list purchased from a marketing vendor two years ago and sends its first broadcast. 640 rows come back with 131026, roughly a fifth of the list, most of them numbers that were never on WhatsApp or belonged to someone who has since changed numbers. VGraple CRM marks all 640 as not reachable with the date, excludes them automatically from the store's next campaign, and the store's real delivery rate on future sends is calculated against the remaining 2,360 contacts, not diluted by an aging, unverified list.
Prevention
The strongest prevention is verifying numbers at the point of entry rather than discovering problems from broadcast failures: prefer contacts who reached you through a channel that confirms a working number, a WhatsApp-initiated conversation, a click-to-WhatsApp ad, or a form where the phone step includes an OTP, over numbers gathered from a form field with no verification. When importing an older or third-party list, expect a real failure rate on the first send and treat it as normal list decay rather than a platform problem; a list untouched for a year or more routinely has 10 to 20 percent of numbers that no longer resolve. Regularly reviewing and removing contacts marked not reachable, rather than leaving them in every future audience, keeps your delivery-rate metrics honest and avoids wasting daily messaging budget on numbers that are very unlikely to ever succeed.
Is 131026 the same as being suppressed?
No, and the distinction matters for how VGraple CRM treats the two. A 131026 failure means Meta accepted your API call and then genuinely tried and failed to deliver the message, so it counts as a failed send, not a suppression. A suppressed recipient (see why a recipient was suppressed) means VGraple CRM refused to attempt the send at all, for reasons like an opt-out, a block set inside the CRM, or the recipient sitting inside a Meta frequency-cap window. A contact who has previously failed with 131026, however, is checked before future sends and skipped with that history shown, which behaves similarly to suppression in practice even though the original event was a genuine delivery failure rather than a pre-flight refusal.