A WhatsApp Business API error code is Meta's machine reason a message failed — and most of them are not your bug. 131047 means the 24-hour window closed (send a template), 131026 means the recipient cannot receive the message, 131049 is Meta throttling marketing, 131042 is a billing/eligibility block, 190 is a dead access token, and 368 is a temporary policy block. This guide decodes the error codes an Indian business actually hits in 2026, gives the fix for each, and — most usefully — tells you whose fault it is so you stop debugging the wrong side. Verify every code against Meta's current Cloud API error reference, which changes periodically.
Where these error codes come from
On the official WhatsApp Business API (Meta Cloud API), a failure surfaces in one of two places. A send-time error comes back in the API response when you call the messages endpoint — the request was rejected before it ever reached the recipient. A delivery error arrives later, asynchronously, on the status webhook: the message was accepted, given a message ID, then failed on its way to the phone. Both carry a numeric code and a human title/message. The number is the thing to search — the wording changes, the code is stable.
Two practical consequences. First, a message can get a wamid (message ID) and still fail — success at send time is not delivery. Second, the error object is often nested; log the whole errors[] array, not just the top-level HTTP status, or you will chase a generic "400 Bad Request" when the real reason sits one level down. Everything below is "verify against the live Meta reference as of 2026" — Meta renumbers and re-scopes codes over time.
The fastest triage: whose fault is it?
Before the full catalog, the single most useful cut. Most wasted debugging time comes from fixing the wrong side of the connection. Sort every failure into one of three buckets first:
| Bucket | Typical codes | What it means |
|---|---|---|
| Your setup | 190, 100, 131042, 133xxx, template errors | Token, permissions, billing, number registration or template are wrong on your side — fixable by you. |
| Meta / policy | 131049, 368, 131048, 130429, 131031 | Meta is throttling, rate-limiting or restricting you for quality/policy reasons — fix behaviour, then wait. |
| The recipient | 131026, 131047, 131051 | The number can't receive this message right now (not on WhatsApp, window closed, unsupported type) — nothing to "fix" in code. |
If you only remember one thing: a burst of 131026 means your list is bad, a burst of 131049/131048 means your sending behaviour is bad, and a single 190 means your token died. Three completely different fixes.
Access token & permission errors (your setup)
190 — access token expired or invalid
The most common "everything suddenly stopped" cause. A short-lived or rotated token expired, or the token was revoked. Fix: regenerate a valid (ideally long-lived / system-user) token and update it wherever your app stores credentials. If sends died all at once across every number, suspect the token before anything else.
100 — invalid parameter
A catch-all for a malformed request: a missing required field, a wrong phone_number_id, an unsupported parameter, or a permission the token does not hold (for example calling a catalog or flow endpoint without the required scope). Read the nested error_data — it usually names the exact offending field. This is a request-shape bug, not a WhatsApp-policy issue.
131031 — account locked / disabled
The WhatsApp Business Account or the specific number has been restricted or disabled, often after repeated policy violations or a failed review. This is not a code fix — it needs the account issue resolved (appeal / verification) before sending resumes. See quality-rating recovery for what drives numbers into restriction.
The 24-hour window & re-engagement errors (the recipient / timing)
These are the codes people misread most, because the message "failed" but nothing is broken — you just sent the wrong kind of message for the moment.
131047 — re-engagement message / outside 24-hour window
You tried to send a free-form (non-template) message more than 24 hours after the customer last messaged you. Outside that service window you may only send a pre-approved template. Fix: send an approved utility/marketing template instead, or wait for the customer to re-open the window by messaging you. Not a bug — it is the platform working as designed.
470 — re-engagement (legacy window-expired)
An older variant of the same 24-hour-window failure seen in some accounts/logs. Same root cause, same fix: a template is required because the free-form window has closed.
131051 — unsupported message type
The message type you sent isn't supported for that recipient or context. Fix: fall back to a supported type (text/template/media as appropriate) for that thread.
Get a 1-minute BSP audit on WhatsApp
Drop your WhatsApp number — we line-item your current invoice against Meta India rates in under 60 seconds. India-hosted, DPDP-compliant.
131047 almost always means "you needed a template here," not "the API is broken."Delivery failures on the recipient side
131026 — message undeliverable
The recipient cannot receive the message. Common real causes: the number is not on WhatsApp, is an invalid/mistyped number, is on an incompatible WhatsApp version, or has not accepted the latest terms. A spike of 131026 across a campaign is the classic symptom of a stale or scraped contact list — the fix is list hygiene, not code. One-off 131026 to a hand-typed number is usually a typo.
131000 — generic "something went wrong"
An unspecified internal error on Meta's side. Usually transient. Fix: retry with backoff; if it persists across many messages, check the Meta platform status and your payload for anything unusual.
Throughput, quality & policy throttles (Meta's side — fix behaviour)
This cluster is where Indian broadcasters get burned, because the message "sent fine" for a while and then a wall of failures appears. These are Meta deliberately slowing or blocking you.
131049 — marketing message throttled for quality
Meta is limiting how many marketing-category messages it delivers to a given user to protect their experience — the message is dropped, not permanently failed. This is a throttle, not a bug. It rises when you push marketing volume at users who don't engage. Fix: send fewer, more relevant marketing messages to opted-in, engaged contacts; lean on utility templates where appropriate. (This exact code is expected background noise on a healthy marketing account — do not treat every 131049 as an incident.)
131048 — spam rate limit hit
The number's send rate/quality tripped a spam limit. Fix: slow down, clean the list, and let quality rating recover. Repeatedly hitting this is what drives a number toward restriction.
130429 / 80007 — rate limit / throughput exceeded
You exceeded the messages-per-second or API-call throughput allowed for your tier. Fix: throttle your sender, add backoff, and respect your current messaging tier. See messaging limits & tiers for how the ceilings step up.
368 — temporarily blocked for policy violations
The account is in a temporary block after policy violations. Fix: stop the offending behaviour (usually unsolicited/aggressive sending), wait out the block, and correct what triggered it. No provider can honestly promise "no ban" — bulk sends to non-consenting users are exactly what causes this.
Billing & eligibility errors (your setup)
131042 — business eligibility / payment issue
The account is not eligible to send because of a billing or business-eligibility problem — no valid payment method, an unpaid balance, or incomplete verification. This is the sneaky one: health status can read "available" while sends still fail with 131042, because billing is enforced at delivery. Fix: sort the payment method and complete Meta Business Verification. Going fully live in India effectively requires GST to finish verification and unlock higher limits — treat GST as required, not optional.
Template errors (your setup)
Template failures are their own family, usually in the 132xxx range, and they mean the message and the approved template don't match — or the template is no longer usable.
| Code | Meaning | Fix |
|---|---|---|
132000 | Parameter count mismatch — variables sent ≠ variables in the approved template | Send exactly the number of parameters the template defines |
132001 | Template does not exist (wrong name or language/locale) | Match the exact template name and language code that was approved |
132005 | Template content translation/hydration issue | Re-check parameter formatting against the approved body |
132007 | Template format/character policy violation | Remove disallowed formatting/characters; re-submit if needed |
132012 | Parameter format mismatch (e.g. bad type in a variable) | Send the parameter in the expected format |
132015 | Template is paused (poor quality) | Wait out the pause / fix quality; see the recovery playbook below |
132016 | Template is disabled (repeated low quality) | Create a fresh, higher-quality template |
Prevention beats debugging here: get templates approved cleanly the first time (template rejection fixes) and keep them out of the paused/disabled states by keeping quality high and content honest. A paused template can often be recovered rather than rebuilt.
Media & number-registration errors (your setup)
Media errors (131052 / 131053)
Media download or upload failed — the file is too large, an unsupported format, or (for local-region WABAs in 2026) an inbound media link that has already expired. Fix: validate size/type before sending, and download inbound media on receipt rather than assuming it stays available.
Registration errors (133xxx)
The number's registration/PIN/deregistration state is wrong — for example a 133xxx when the number isn't registered on Cloud API, or a two-step-verification PIN mismatch. Fix: complete (or reset) number registration with the correct PIN before sending.
A logging habit that ends most of this
The teams that never panic about error codes do three boring things:
- Log the full
errors[]object (code + title +error_data.details), not just the HTTP status — the real reason is almost always in the nested detail. - Consume the status webhook so you catch delivery-time failures (
131026,131049) that never appear in the send response — a message with awamidcan still fail later. - Alert on ratios, not single events. One
131026is a typo; 40%131026is a dead list. One131049is normal; a131048/368is a behaviour problem to fix now.
On RichAutomate this is handled for you: failures are captured with their code, delivery status flows back through the webhook, and refunds on failed billable sends are idempotent so a retry never double-charges. See how billing handles failed messages.
Bottom line
WhatsApp Business API error codes look intimidating but resolve to a short triage: is this your setup (190, 100, 131042, template 132xxx), Meta throttling you (131049, 131048, 368, 130429), or the recipient (131026, 131047)? Fix your side, change behaviour for Meta's side, and stop debugging the recipient's side. Log the full error object, read the status webhook, and alert on ratios. Verify each code against Meta's current Cloud API error reference as of 2026 — the semantics shift over time. See the platform on features and pricing.