Every request to the WhatsApp Cloud API stops working at the same moment. Message sends, template fetches, webhook subscriptions all return the same JSON body, and the code inside it is 190.
Meta documents error 190 as "Access token has expired" with an HTTP status of 401, and the recommended action is to obtain a fresh access token before retrying (Meta for Developers, WhatsApp error codes reference, retrieved 2026-08-17). That fix is accurate but incomplete, because most teams hit error 190 again a few weeks later. The durable fix is choosing the right type of token in the first place.
This guide covers the three token types Meta issues, how long each survives, the steps to create one that does not expire, and how to rotate credentials without taking messaging offline. For the wider failure surface, our WhatsApp Business API error codes reference indexes the full set.
Key Takeaways
- 131026 is a delivery failure, not an authentication or template failure. Your credentials and template were fine; WhatsApp accepted the request and then could not hand the message to the recipient.
- Five distinct causes hide behind one code: number not on WhatsApp, malformed number, business blocked by the recipient, Terms of Service not accepted, and an outdated WhatsApp client.
- Only two of the five are meaningfully retryable. Retrying the other three burns throughput and can degrade your quality rating without ever delivering.
- The highest-yield fix is upstream: normalise numbers to E.164 at collection time, before they enter a send queue.
What Error 131026 Means, and What It Rules Out
The response body looks like this:
{
"error": {
"message": "(#131026) Message undeliverable",
"type": "OAuthException",
"code": 131026,
"error_data": {
"messaging_product": "whatsapp",
"details": "Message Undeliverable."
},
"fbtrace_id": "AbCdEfGhIjK"
}
}Before diagnosing, note what 131026 rules out. Your access token authenticated, so this is not error 190 or an expired credential. Your template existed and was approved, or you would have received 132001. Your parameter count matched, or you would have received 132000. You were inside your rate limits, or you would have received a throttling code.
What remains is the last mile: WhatsApp tried to route the message to a specific handset and could not. That narrows the problem to the recipient, the number, or the relationship between the recipient and your business.
Worth flagging to finance: because the message was never delivered, it does not become a billable delivered message under the per-message pricing model Meta adopted on 1 July 2025 (Meta for Developers, Pricing, retrieved 2026-08-17). A high 131026 rate costs you reach and sender reputation rather than spend, which is why it goes unnoticed for so long.
The Five Causes: A Diagnostic Tree
Work these in order. The first two are the cheapest to check and the most common.
# | Cause | How to confirm | Retryable? | Fix |
|---|---|---|---|---|
1 | Number not in E.164 format | Inspect the exact string you sent | Yes, after correction | Normalise to country code + number, digits only |
2 | Number has no WhatsApp account | Number is valid but consistently fails across templates and time | No | Suppress; route to SMS or voice |
3 | Recipient blocked your business | Previously delivered to this number, now fails permanently while others succeed | No | Suppress permanently; treat as an opt-out signal |
4 | Terms of Service not accepted | New WhatsApp user, or a reinstalled account that never completed onboarding | Yes, later | Retry after 24–48 hours, once |
5 | Outdated WhatsApp client | Message type is newer than the recipient's app supports | Yes, with a fallback | Resend as plain text; suppress rich formats for that number |
Cause 1: The number is not in E.164 format
The largest single contributor in most audits, and the easiest to fix. WhatsApp expects country code followed by subscriber number, with no plus sign, spaces, hyphens, parentheses, or leading trunk zero.
What you send | Result |
|---|---|
| Correct — India, E.164, no symbols |
| Rejected or misrouted |
| Rejected — leading trunk zero, no country code |
| Rejected — hyphen |
| Rejected — no country code |
The failure mode that catches teams out is a CRM export. A spreadsheet column formatted as a number silently strips leading zeros, converts long numbers to scientific notation, and re-adds locale separators. If your 131026 rate spiked after a data import, check the raw strings first.
Normalise at collection, not at send time. A library such as libphonenumber, given the subscriber's country, produces a canonical E.164 value once instead of every downstream system guessing. Our guide to sending WhatsApp messages without saving contacts covers the number-handling mechanics.
Cause 2: The number has no WhatsApp account
A valid mobile number belonging to someone who does not use WhatsApp returns 131026 every time. No API lets a business check WhatsApp registration for an arbitrary number in advance, by design, since that would enable enumeration of the user base.
The workable approach is empirical. Track failures per number, and after two or three 131026 responses across different sends and days, mark it as not-on-WhatsApp and stop attempting it. In markets where WhatsApp penetration is uneven, treat this as a normal share of any cold list and build a channel fallback rather than a retry loop. Our comparison of WhatsApp versus SMS for notifications covers when that fallback earns its cost.
Cause 3: The recipient blocked your business
The cause with the most operational weight and the least visibility, because WhatsApp deliberately does not tell you a specific user blocked you. Doing so would expose the recipient.
The signature is temporal: this number received your messages in the past, now returns 131026 consistently, and comparable numbers in the same batch deliver normally. That pattern is a block in all but name.
Treat it as a hard opt-out. Retrying a blocked recipient cannot succeed, and repeatedly sending to people who have blocked you is what pulls down your WhatsApp quality rating and eventually caps your messaging limits. If blocks are rising across the list rather than on isolated numbers, the problem is frequency or relevance, not deliverability. See WhatsApp marketing mistakes for the usual causes.
Cause 4: The recipient has not accepted WhatsApp's Terms of Service
Meta names Terms of Service acceptance explicitly in its recommended action. This affects a small population: users who installed WhatsApp but never completed onboarding, or reinstalled and stalled partway through. The account exists; it cannot receive business messages yet.
This one is genuinely transient. One retry after 24 to 48 hours is reasonable. If it fails again, move the number to suppression.
Cause 5: The recipient's WhatsApp app is too old
An outdated client can fail to render newer constructs: some interactive types, certain button layouts, newer media handling. Meta's guidance to confirm the recipient "runs current version" points here.
The diagnostic is a controlled downgrade. Resend the same message as plain text. If the text version delivers and the rich version does not, the client is the constraint. Build a fallback that degrades gracefully for those numbers rather than dropping them, particularly if you use carousel templates or quick reply buttons at volume.
How Should You Handle Retries for 131026?
The most damaging response to 131026 is a blanket retry policy, because three of the five causes are permanent. Retrying them consumes throughput and accumulates failed-send signals against your sender. A defensible policy separates the cases:
- Formatting failures — correct the number and send once. Do not retry the malformed string.
- Terms of Service — one retry, after 24 to 48 hours.
- Client version — one retry, downgraded to plain text.
- Not on WhatsApp — no retry after two or three confirmed failures. Suppress.
- Blocked — no retry, ever. Suppress and treat as opt-out.
Implement this as a per-number failure counter, not a global retry rule. Two consecutive 131026 responses on a number that never delivered should trigger suppression. Two on a number with prior successful delivery should trigger suppression and be counted as a probable block, which is a signal your lifecycle team needs. Tracking these separately in your WhatsApp analytics turns a flat error count into a list-health metric.
On measurement: a warm list built on proper opt-in should show a low, stable 131026 rate, and the trend matters more than the absolute number. A sudden spike almost always means a data pipeline change. A slow rise on a previously stable list usually means blocks accumulating, which is a content problem wearing a technical costume.
Frequently Asked Questions
What are the top causes of WhatsApp error 131026?
In descending order of frequency in most audits: a phone number not in E.164 format, a number with no WhatsApp account, a recipient who has blocked the business, a recipient who has not accepted WhatsApp's Terms of Service, and an outdated client that cannot render the message type. Meta's recommended action names the last three; the first two are what teams find in their own data.
How can I check whether a number is on WhatsApp before sending?
You cannot, and that is intentional, since an API confirming WhatsApp registration for arbitrary numbers would enable enumeration of the user base. The workable substitute is empirical suppression: track 131026 failures per number and mark it unreachable after two or three failures across different sends and dates.
Can I retry a message that returned 131026?
Only for two of the five causes. A corrected number format and a Terms of Service issue justify a retry; an outdated client justifies one retry as plain text. A number with no WhatsApp account, or a recipient who blocked you, will never accept the message, and repeated attempts risk your quality rating with no chance of delivery.
Does error 131026 mean the recipient blocked me?
Sometimes, but WhatsApp will not confirm it, because that would reveal the recipient's action. The reliable signal is a pattern rather than a single response: a number that previously received your messages, now failing consistently, while comparable numbers in the same batch deliver.
Was I charged for a message that failed with 131026?
No. Under the per-message pricing model Meta introduced on 1 July 2025, an undelivered message does not become a billable delivered message. The cost of a high 131026 rate is lost reach and sender reputation rather than a line on your invoice, which is why it often goes untracked.
What is the difference between error 131026 and error 131047?
They fail at different layers. 131026 means WhatsApp could not deliver to the recipient at all. 131047 means delivery was possible but your message type was not permitted, because the 24-hour customer service window had closed and a free-form message was sent where a template was required. See error 131047 and the 24-hour window.
Turning a Flat Error Count Into a Clean List
Error 131026 rewards diagnosis and punishes retries. Teams that split it into five causes and suppress the three permanent ones see the error rate fall and, more usefully, see their quality rating stabilise, because they stopped repeatedly messaging people who cannot or will not receive them.
The upstream fix does most of the work. Normalise every number to E.164 at collection, before it reaches a queue. That one change removes the largest cause of 131026 and prevents the CRM-import spike behind the worst incidents.
Want delivery diagnostics you do not have to build? Helo.ai is a Meta Partner and surfaces per-number failure reasons, automatic suppression, and channel fallback across WhatsApp, SMS, and voice from one platform. Talk to an expert.
Next: if your delivery rate is healthy but engagement is not, read why WhatsApp messages are not being delivered for the wider diagnostic, or error 131047 if free-form sends are being rejected.
