The WhatsApp API error codes you will actually hit

The official WhatsApp Business API error list is long. In practice, if you integrate messaging with a CRM, you will run into a very specific handful again and again. This guide covers those, with the context the documentation assumes you already have.

131047: Re-engagement message

What it means: you tried to send free-form text outside the 24-hour window.

Why it is confusing: because the send returned 200. Meta accepts the message, gives you an id, and discards it afterwards. The error only shows up in the status update that arrives by webhook.

Fix: outside the window, only an approved template can be sent. There is no shortcut. If your automation writes to contacts who have not written to you, it must always use a template.

131008: Required parameter is missing

What it means: the template you are sending declares a parameter you are not filling in.

The case that comes up most: a URL button with a variable inside the address (https://…/{{1}}). Registered that way, the template requires a button component on every send. Many automation tools offer no field for that value, so the template ends up approved but unsendable.

Fix: register the button with a static URL and move the variable into the message body. If the template already exists, you will have to duplicate it corrected, because the button type of an approved template cannot be changed.

190: Cannot parse access token

What it means: what you are sending is not a valid token.

Why it appears when "the token is correct": almost always because what goes out is not the token but its encrypted form, or a string truncated on save. It is a storage bug, not a permissions one.

Fix: check what literally reaches the Authorization header. If you store tokens encrypted, and you should, make sure they are decrypted immediately before use.

132000 and friends: template and parameters do not match

What it means: the number of variables you send does not match what the template expects.

Fix: treat the template as a contract. Three variables means three values, in order. A template edited in Meta and not updated in your system breaks here.

368 and quality restrictions

What it means: your number has been rate-limited on quality, usually because a high share of recipients blocked or reported your messages.

Fix: this one is not solved in code. It is solved by sending less and better: to people expecting your message, with templates that are worth receiving. Quality rating recovers over time if the behaviour changes.

The error with no code

The most expensive one appears on no list: counting the 200 as a delivery.

The API answers 200 when it accepts a message for processing. What happens next arrives by webhook, as a sequence of statuses:

sent  →  delivered  →  read
failed + error code

If your system does not listen to that webhook, or listens but never persists the status, your report will say everything went fine. It is a silent failure: nobody sees an exception, nobody gets an alert, and the number you are looking at is simply false.

A row that says sent forever because nobody wrote the webhook result is worse than a row that says failed. You investigate the second one.

How to diagnose a send properly

1. The synchronous response only confirms acceptance. Store the message id and move on.
2. The verdict is in the status webhook. Persist it against that id.
3. Record the error code, not just the failure. 131047 and 131008 have opposite causes and opposite fixes; "failed" tells you nothing.
4. Check in advance what can be checked. Window state and template shape are both knowable before you send. Firing something you know will fail only damages your number's quality rating.

Summary

And the one with no number: measuring acceptances and calling them deliveries.