WhatsApp error 131049: sent, accepted, never delivered
Your API call returned 200. You got a message id back. Nothing arrived. This is the single most common WhatsApp delivery failure we see, and almost nothing accurate is written about it.
Short answer. 131049 is Meta's per-user marketing frequency cap — "This message was not delivered to maintain healthy ecosystem engagement". Meta accepts the send, returns 200 with a wamid, then declines to deliver it because that person has already had too much marketing recently. It is not a ban, not a block and not a bug in your code. If the content is genuinely transactional, resubmitting the identical template as UTILITY fixes it — and costs less.
How common is it, really?
We run WhatsApp for UAE brands, so rather than guess, here is the failure breakdown from one account we operate — JustHype, a UAE retail brand — covering 14,899 messages to 3,293 contacts between 18 June and 22 August 2026:
| Error code | Meaning | Count | Share of failures |
|---|---|---|---|
| 131049 | Marketing frequency cap | 1,388 | 89.1% |
| 131026 | Message undeliverable (recipient cannot receive) | 111 | 7.1% |
| 130472 | User is in a Meta marketing experiment group | 51 | 3.3% |
| 131050 | User has opted out of marketing | 6 | 0.4% |
| 131053 | Media upload error | 2 | 0.1% |
Nearly nine in ten delivery failures were this one error. Measured the other way — against marketing template sends specifically — 1,172 of 14,064 marketing messages were dropped, or 8.3%. Total failures across all sends were 1,557, about 10.5%.
Source: JustHype WhatsApp Business API account, United Arab Emirates, 18 Jun – 22 Aug 2026. One account, one market, one brand's sending pattern. Your rate will differ.
Why the send looks successful
This is the part that costs people a campaign. The frequency cap is applied at delivery time, not at send time. So the sequence is:
- You POST the message. Meta returns HTTP 200 and a
wamid. - Your system records a success, because that is all the send response tells you.
- Some time later a status webhook arrives carrying
131049. - Nothing was delivered. No error was ever raised in your send path.
If you are not storing and reading webhook status events, this failure is completely invisible to you. A whole campaign can vanish while your dashboard shows it as sent. That is the real damage 131049 does — not the drop itself, but the silence.
The test that proves it is the category, not you
On a separate Adjoltz account — a Dubai wedding-security business — we hit this on a specific number and ran a controlled check on 8 August 2026:
| Template | Category | Same recipient? | Result |
|---|---|---|---|
| Campaign invite (video, buttons) | MARKETING | Yes | Failed 131049, twice |
hello_world | UTILITY | Yes | Sent → delivered → read |
| Same invite, resubmitted | UTILITY | Yes | Approved by Meta, delivered |
Identical number. Identical minutes. The only variable was the template category. The resubmitted template kept the same copy, same video and same buttons — Meta approved it in both Arabic and English — and it was billed at pricing_category=utility, which is cheaper than marketing.
This is a single controlled observation, not a statistical result. It is decisive about cause on that number; it does not prove utility templates are never capped.
Diagnose it in five minutes
- Look at the status webhook, not the send response. If you have no webhook log, start there — you are flying blind on every delivery failure, not just this one.
- Send
hello_worldas a utility control to the exact number that failed. If the control lands and your campaign did not, it is the category. If the control also fails, the problem is the recipient or the number. - Check whether your content is honestly utility. Order updates, booking confirmations, appointment reminders, tickets and RSVPs are utility. Promotions, offers and newsletters are marketing.
The fix
If the content is genuinely transactional
Resubmit the identical template with category UTILITY. Same copy, same media, same buttons. Once approved, send again to the same people. You get delivery, and you pay the utility rate (~AED 0.058) instead of the marketing rate (~AED 0.183) — see the UAE rate card.
If the content is genuinely promotional
Then it belongs in marketing and you should not relabel it. Meta does review categories, and mislabelling promotional content as utility risks the template and the account. Your real options:
- Wait and retry. The cap decays per user, so the same person may be reachable in days rather than hours.
- Send less, to fewer people. The cap exists because the recipient is being over-messaged — usually by everyone, not just you.
- Flag the undelivered contacts and reach them another way rather than pretending the campaign landed.
- Let the customer open the conversation. A Click-to-WhatsApp ad opens a 24-hour window in which you can reply free-form — no template, no category, no cap.
What good looks like. On the same JustHype account, of the marketing messages Meta actually billed us for, 79.2% were read (5,415 of 6,834). WhatsApp engagement in the UAE is genuinely high. The frequency cap is the thing standing between a campaign and that number — which is why category discipline matters more than copy.
What 131049 is not
- Not a ban. A ban hits your number or WABA and stops everything. This is per recipient, per message.
- Not a block. A user block is code 131050 territory, or simply no delivery at all.
- Not a quality-rating problem. Your rating can be Green while this happens all day.
- Not your provider's fault. No platform can override it. Any vendor claiming they can bypass Meta's frequency cap is not telling you the truth.
Adjoltz runs WhatsApp for UAE brands on Meta's official Cloud API — including the unglamorous part: webhook status logging, template categorisation and catching failures like this before a campaign is wasted. Zero markup on Meta's rates, from $149/month.
Frequently asked questions
What does WhatsApp error 131049 mean?
It means "This message was not delivered to maintain healthy ecosystem engagement" — Meta's per-user marketing frequency cap. Meta accepts the send, returns 200 with a message id, then declines to deliver it because that person has already received too much marketing recently. Not a ban, not a block, not a fault in your code.
How common is error 131049?
On a UAE account we operate it was 1,388 of 1,557 delivery failures — 89.1% — across 14,899 messages between 18 June and 22 August 2026. Against marketing sends specifically, 1,172 of 14,064 were dropped, or 8.3%. It is by a wide margin the most common WhatsApp delivery failure.
Why did the API return success if the message failed?
The cap is applied at delivery time, not send time. The API returns 200 with a wamid, so code that only checks the send response records a success. The failure arrives later as a status webhook. Without stored webhook events the failure is invisible and a campaign can vanish silently.
How do I fix error 131049?
If the content is genuinely transactional, resubmit the identical template as UTILITY. On our account a marketing template that failed 131049 twice to a number was approved and delivered to that same number as a utility template with identical copy, media and buttons — and billed at the cheaper utility rate. If the content is genuinely promotional, keep it marketing and instead retry later, follow up manually, or use a Click-to-WhatsApp ad so the customer opens the window first.
Is 131049 the same as being banned?
No. A ban affects your number or WhatsApp Business Account and stops everything. 131049 is per recipient and per message — your number stays healthy and utility or service messages to the same person still arrive.
Does sending less often reduce 131049?
It should, since the cap is per user and decays, but we cannot put a figure on it from our own data. What we can show is that the cap is real, that it dominates failures, and that categorising transactional content correctly removes it for that content.