You send a campaign to 10,000 people. The dashboard says 10,000 sent. Replies trickle in at a fraction of what you expected, and nothing anywhere says why.
A large share of those messages were never delivered, and the reason has a number: 131049.
What error 131049 actually means
Meta's description is that the message was not delivered to maintain a healthy ecosystem. In practice it is a per-recipient marketing cap: Meta limits how many marketing messages a given WhatsApp user receives across all businesses, and when someone is at their limit, your message is dropped.
Three consequences of that definition, and they matter:
It is about the recipient, not you. The cap belongs to the person receiving it. Two people on the same campaign, same template, same second: one gets it, one does not, because one had already received marketing from other businesses that day.
It only applies to MARKETING. Utility and authentication templates are not subject to it. Which means the same message can succeed or fail depending on the category Meta assigned to it, and Meta re-categorises templates by content regardless of what you picked.
It is temporary. The same person may be reachable tomorrow. This is the one error code where retrying later is genuinely sensible.
The part that makes it dangerous
Here is the sequence, and it is the reason 131049 goes unnoticed:
- You call the API to send the message
- Meta accepts it and returns a message id
- Your tool records a success. The campaign shows "sent"
- Minutes later, a webhook arrives saying that message failed with 131049
- If nothing is listening to that webhook, step 4 never happened as far as your dashboard is concerned
We can be precise about this because we checked. In our own production logs, all 44,345 messages that hit 131049 had a message id from Meta. Every one had already been accepted. The rejection was always after the fact.
So "sent" is not a delivery number. It is a record that Meta took the request. There is more on this in why "sent" means nothing in the WhatsApp Cloud API.
What it looks like at volume
Numbers from our own production, between 4 July and 5 August 2026:
| Error code | What it means | Occurrences |
|---|---|---|
| 131049 | per-recipient marketing cap | 44,345 |
| 131047 | outside the 24-hour window, needed a template | 2,760 |
| 131026 | not a WhatsApp user | 923 |
| 130472 | recipient in a Meta experiment group | 126 |
Two honest caveats about that table, because a number without context is misleading.
It is concentrated on one account. 44,329 of the 44,345 came from a single high-volume account pushing marketing templates at a large list. The other accounts in the same period recorded 13 and 3. This is not "WhatsApp fails most of the time"; it is what happens to one specific sending pattern.
That is the point. 131049 is not a random error rate you can average across a platform. It is what the per-recipient cap does to marketing at volume, and the more marketing you push at a list, the larger a share of it this becomes.
How to tell if it is happening to you
You almost certainly cannot see it in a "sent" count. Three places to look instead:
Compare delivered against sent, not sent against your list. If your tool cannot show you delivered, it cannot show you this at all, and that is itself the finding.
Look for a gap that scales with volume. A 500-message send may look fine. The same template to 20,000 will not. If your reply rate falls as your list grows, suspect the cap before you blame the copy.
Check the template's billed category. If a template you thought was utility is being billed as MARKETING, it is exposed to the cap. Meta decides the category from the content, not from what you selected, which is covered in why your template keeps getting billed as MARKETING.
What to do about it
Retry, but later and not in a loop. 131049 is temporary, so a retry has a real chance. A retry immediately does not, and sustained failed sending is exactly what damages a quality rating. Hours, not seconds, and cap the attempts.
Do not treat it like 131026. That code means the number is not on WhatsApp. It is permanent and retrying it forever is pure waste. The two look similar in a log and deserve opposite handling. The full retry-or-never table is in WhatsApp Cloud API error codes.
Move what you can out of MARKETING. An order update, an appointment reminder, a delivery notification genuinely is utility. Written as utility, it is not subject to the cap and it is cheaper. Written with a promotional line bolted on, Meta will re-categorise it and you get both the cap and the higher price.
Send less marketing to more relevant people. Unsatisfying, and it is the actual answer. The cap exists because users receive too much marketing. A list you message weekly burns through recipients' allowances; a list you message when you have something worth saying does not.
Make sure something is listening to webhooks. If your tool does not consume delivery webhooks, none of the above is visible to you. Ask your provider directly whether the campaign report is built from send responses or from delivery webhooks. Those are different numbers and only one of them is true.
The uncomfortable summary
If you run marketing campaigns on WhatsApp at any scale, some proportion of every send is being dropped by Meta before it reaches anyone, and your dashboard is probably reporting those as successes.
The number is not a percentage you can look up. It depends on your template's category, how much marketing your recipients already get, and how often you message them. What you can do is measure delivered instead of sent, and stop optimising copy for messages nobody received.
Questions people ask
What does WhatsApp error 131049 mean?
Meta declined to deliver that marketing message to that specific recipient in order to limit how much marketing a WhatsApp user receives across all businesses. It is a per-recipient cap, it applies only to MARKETING-category templates, and it is temporary, so the same person may be reachable later.
Why does my WhatsApp campaign say sent but people did not receive it?
Because "sent" only records that Meta accepted the request. With 131049 the API call succeeds and returns a message id, then the rejection arrives minutes later as a delivery webhook. A tool that does not consume those webhooks counts the message as a success permanently.
Should I retry a message that failed with 131049?
Yes, but later and with a limit. The cap is temporary so a retry has a genuine chance, unlike 131026 which means the number is not on WhatsApp and should never be retried. Retrying immediately or in a loop achieves nothing and sustained failed sending damages your quality rating.
How do I avoid error 131049?
Reduce exposure to the marketing category. Genuine utility messages such as order updates and appointment reminders are not subject to the cap, provided they are written as utility rather than carrying promotional content, since Meta assigns the category from the content. Beyond that, messaging a list less often preserves recipients' allowances.
Does 131049 apply to utility and authentication templates?
No. The per-recipient cap applies to MARKETING-category messages. However, Meta re-categorises templates based on their content, so a template you submitted as utility can be billed and treated as marketing if it reads promotionally.
How common is error 131049?
There is no fixed rate, because it depends on your template category, your send frequency and how much marketing your recipients already receive. For scale: we logged 44,345 occurrences in one month across our own production, overwhelmingly concentrated on a single account sending marketing templates to a large list.
Stop losing leads to the follow-up gap
Kredoo captures leads from Meta and Google Ads, then follows up on WhatsApp automatically. Live in 5 minutes.
Get Started