Error 131026 · HTTP 400

Message undeliverable

A bucket error that most references describe as one thing, and that we had wrong ourselves.

Cause. A bucket error. Meta groups several unrelated failures under this one code: the number is not on WhatsApp, the recipient is on a very old client, the recipient has not accepted current terms, or the message type is not permitted for that destination. The last of those is a hard platform rule rather than anything about the person: authentication templates cannot be delivered to +91 India numbers at all.

Fix. Read it as "this message could not be delivered", not "this person is unreachable". Suppressing on it blindly will permanently silence contacts whose only problem was the template category, which on an India-heavy audience means suppressing people you could still reach with a utility template or a user-initiated reply. Suppress only where you have separate evidence the number is not on WhatsApp.

It is several failures wearing one code

Meta groups unrelated problems under 131026: the number is not on WhatsApp, the recipient is on a very old client, they have not accepted current terms, or the message type is not permitted for that destination. The response body does not tell you which.

That matters because the standard advice everywhere is "suppress the contact". For the first case that is right. For the others it permanently silences somebody who was reachable.

The India trap

Authentication templates cannot be delivered to +91 India numbers. Not rate limited, not sometimes: it is a hard platform rule, and the refusal comes back as 131026.

On an India-heavy audience, a platform that suppresses on 131026 will therefore walk a large part of a legitimate contact list into permanent silence the first time somebody sends an authentication template — for a rule about template categories that has nothing to do with any of those people. Those same contacts would have received a utility template without complaint.

What we changed

Our own corpus described this as "the recipient cannot receive the message" and told readers to suppress. That was the received wisdom and it was incomplete, so it now describes the bucket and says to suppress only where you have separate evidence the number is not on WhatsApp.

This error has occurred 50 times on our deployment. None of them produced a suppression, because they arrived as delivery webhooks rather than send-API responses and never reached the classifier. That gap turned out to be protective, which is a poor reason to keep something and a good reason to have looked.