WhatsApp error 131049: the marketing message Meta decided not to deliver

What Meta answers when it decides not to deliver

The Error codes page of the Cloud API documentation describes 131049 in one sentence that says a lot through what it leaves out: “This message was not delivered to maintain healthy ecosystem engagement.” It does not mention an invalid number, a rejected template or a restricted account. It talks about the ecosystem — the inbox of the person who was going to receive the message. The error does not tell you something broke on your side. It tells you Meta chose not to deliver.

It also does not arrive where many integrations look for it. The call to /messages comes back with HTTP 200, a wamid and a message_status of accepted, like any successful send. The refusal comes later, in the messages webhook: a failed status, with the code inside errors[] and the explanation in error_data.details. If you count everything the API accepted as delivered, you count 131049 as a success — and the campaign reports a delivery rate that never happened.

One implementation detail that saves rework: compare the code, not the text. The error codes page itself warns that the title attached to each error will be deprecated, and asks you to build your handling on code and details. Error text gets reworded without notice; the number stays. And error_subcode, which some older integrations still read, has not been returned since version 16.0 of the API.

A per-person limit that adds up marketing from every business

The most common cause of 131049 is the per-user marketing limit, described on the Per-user marketing template message limits page. WhatsApp may limit how many marketing templates a person receives “from any business in a given period of time” when they are less likely to be receptive to them. From any business: the ceiling is not between you and your customer, it is between your customer and everyone who sends them marketing.

The criterion is not fixed either. According to the same page, Meta decides based on several factors, including that person's recent marketing read rate and how many messages they currently have in their inbox — from friends, family and businesses. The limit adjusts itself to engagement: in weeks of low reading or a crowded inbox, the same person receives less marketing. Meta makes a point of saying that your ability to reach someone when they are most engaged does not change.

That is why there is no number to put in a constant. Vendor blogs still circulate rules such as “two marketing messages a day”, inherited from Meta's early tests in 2024. The current documentation publishes no number at all, and a scheduler built on a fixed quota gets it wrong in both directions: it holds back messages that would have been delivered and releases the ones that are going to hit the limit.

Two counting rules help with planning. Each delivered marketing template counts — a failed one takes no slot. And marketing sent inside a customer service window does not count: when the person replies to a marketing message, the 24-hour window opens, and any marketing you send inside it stays outside the limit. The practical consequence comes further down, but the idea is simple: an open conversation protects delivery.

Why wait 24 hours, and what happens if you don't

Meta's guidance for 131049 is a single one, and it appears both on the error codes page and on the per-user limit page: wait at least 24 hours before resending the template to that person. Resending earlier, the documentation says, will likely produce more errors and reduce the accuracy of your campaign's delivery reporting.

There is a second, less known rule that turns a hasty retry into damage. Meta limits excessive attempts: if the account resends marketing several times within 24 hours to people who have already reached their limit, further attempts to those people may be unavailable for up to 24 hours — with the same 131049. The penalty is per recipient and does not affect sending to anyone else, but the effect on that customer is real: the retry meant to speed up delivery pushes it further away.

We have seen the pattern happen. An agent sent a marketing template from the inbox, got 131049 about a second later and, thinking it was a glitch, clicked resend. The second attempt failed the same way. Since then, the same rule applies at both ends of our product — resending from the conversation and reprocessing a campaign's failures: 131049 only goes back into the queue 24 hours after the failure, and the composer warns before sending marketing to someone Meta refused within that interval.

Twenty-four hours from when? The documentation tells you to wait before resending but does not define the clock. Our reading, which is a recommendation and not Meta's rule: count from the failed status, the moment you learned about the refusal, not from when the message was created. In a campaign scheduled overnight and processed in batches, the gap between the two clocks can be hours — and it is exactly that gap that produces the second 131049.

One campaign, four different failures

131049 rarely shows up alone. In a customer campaign we analysed, the dashboard showed 68 failures, and the request was for a report on what had happened. Measured in the database, they were four different things: 131026 fifty-six times, 131049 six times, 130472 five times and error code 100 once. Four causes, four answers — and two of them the opposite of what the screen suggested.

131026 is the case of a number that cannot receive: no WhatsApp, terms of service not accepted, or an app version that is too old. Resending to the same number changes nothing; what fixes it is confirming the number with the person through another channel. In Brazil, part of these cases is the ninth digit — a mobile number stored in the old format, without the leading 9 — and it is worth checking that before concluding the customer does not use WhatsApp.

130472 is a Meta experiment, described on the Experiments page: a very small percentage of users do not receive marketing from any business unless there is an open customer service window with the sender. Meta does not charge for the message, and resending returns the same error. There is no end date for the experiment and no way to take someone out of it; the way out the documentation offers is to ask the person, through another channel, to message you, and then send with the window open.

131050 is the customer's decision: they used the option to stop receiving marketing from your business. The guidance is not to resend, because the message will not be received, and to subscribe to the user_preferences webhook, which tells you when someone stops or resumes marketing. Finally, 100 is a rejected parameter — wrong data in the template, which can only be fixed in the content. Treating all four as “failed” makes the operator resend what will never go out and give up on what would have gone out the next day.

United States: the 131049 that waiting does not fix

There is a 131049 that has nothing to do with engagement. Since 1 April 2025, Meta does not deliver marketing templates to people with United States phone numbers — the +1 dialling code with a US area code — and the Get started page of the Marketing Messages API states which error comes back: 131049. The restriction applies across all of Meta's messaging APIs, including the Cloud API, and the per-user limit page still describes it in the present tense. No date has been announced for it to end.

In this case, waiting 24 hours is pointless. The reason is structural, not saturation, and the resend comes back with the same code until Meta changes the rule. That is why handling 131049 needs to look at the recipient before it looks at the clock: same code, two causes, two answers. For a US number, the marketing message should not even enter the resend queue — and, better still, it should not go out in the campaign.

The restriction is about marketing. Utility and authentication are still delivered to US numbers, which matters for a business that sells abroad: order confirmations, delivery updates and verification codes keep working. What does not get through is promotion — and a promotional template registered as utility does not solve it, because Meta checks the category against the content and reclassifies what is wrong. A utility template that becomes marketing starts following marketing's rules, this one included.

Where the limit does not apply, and how the window protects delivery

The per-user limit is not active in every market. According to the Get started page of the Marketing Messages API, it does not apply in the European Economic Area, the United Kingdom, Japan, South Korea, Nigeria, South Africa and Thailand — Thailand joined the list in September 2026. Brazil, Mexico and the rest of Latin America are not among the exceptions: if you send to numbers there, 131049 is part of operations.

The counting rule is the best tool Meta leaves in the sender's hands. Marketing inside a customer service window does not count towards the limit, and the window opens when the person writes to you — including by replying to a marketing message. A template with a quick-reply button that the customer taps opens the window; the offer you send in the next 24 hours does not compete for a slot with every other business's messages.

That changes how a campaign is designed. Instead of two cold sends to the same list on consecutive days, a first contact that invites a reply and a follow-up, inside the window, for those who replied. Click-to-WhatsApp ads work on the same logic: whoever arrives through the conversation has already opened the window. It is not a trick. It is the rule Meta wrote, rewarding businesses that converse instead of just broadcasting.

One caveat: the window does not change the category. The message is still marketing and is still charged as marketing, with the window open or closed. What the window changes is only how the per-user limit counts and, with it, the chance of 131049 showing up. And it does not last forever: 24 hours after the customer's last message, the next offer is back to competing for a slot.

What happens before 131049: preference, quality and pacing

The per-user limit is not the only filter between your template and the inbox. The Marketing templates page describes a setting inside WhatsApp itself, called Offers and announcements, where the person says whether they are interested in your business's marketing. Choosing not interested can affect the per-user limit between you and that person — the part of the limit that depends on you alone — and immediately offers the option to stop your marketing entirely. Interested and not interested do not trigger a webhook; only stop and resume trigger user_preferences.

Then comes template quality. Each template has a rating in the quality_score field — GREEN, YELLOW, RED or UNKNOWN — computed from usage, feedback and engagement, such as blocks, reports and low reads. According to the Template pausing page, a template that reaches red is paused for three hours the first time, six the second, and disabled the third. Sending with a paused template fails with 132015 and is not charged; with a disabled template the code is 132016.

And there is pacing. The Template pacing page describes when Meta holds back part of a template's messages to measure the reaction before releasing the rest: the send response comes with a message_status of held_for_quality_assessment instead of accepted, and if early feedback is poor, the held messages fail with 132015. A bad template does not wait for 131049 to be contained.

Finally, do not confuse 131049 with 131048. 131049 is about the recipient; 131048 is about the sender — a sending restriction because earlier messages from the number were blocked or flagged as spam. The first is solved with waiting and relevance; the second calls for checking the number's quality in WhatsApp Manager before sending anything else. And Meta is explicit about a difference that surprises people: on the Cloud API, “Message quality does not factor into per-user marketing message limits”. A good template earns no exception from the per-user limit; it only gets through the other filters.

How to measure the effect on a campaign

131049 needs to become a metric, and Meta does not hand you that metric ready-made. The Analytics page lists the account's analytics, pricing_analytics and template_analytics fields, and none of them breaks failures down by code: pricing_analytics counts only delivered messages, and template_analytics returns sent, delivered, read and clicked. The gap between sent and delivered mixes 131049, 130472, 131026 and everything else. The source of the right number is your own webhook log.

The minimum record, in our experience, has four fields per failure: the wamid, the code, the time of the failed status and the originating campaign or send. With them you can compute, per campaign and per segment, the share of recipients that came back with 131049 — and watch whether it rises. A rate that grows from campaign to campaign on the same list is a sign of saturation: the same people receiving too much marketing, yours and everyone else's.

Compare segments by what the limit measures. If Meta's criterion is recent engagement, people who read, clicked or replied in the last few weeks tend to receive, and people who have ignored everything for months tend to hit the limit. Splitting the list by recency of interaction and looking at 131049 in each slice turns an opaque error into an indicator of list quality — and shows where it is worth sending less, or sending something else.

On cost, the rule on the Pricing page is that a business only pays for delivered messages, and the status webhook reference shows the pricing object travelling with sent, delivered and read, not with failed. 131049 does not appear on Meta's invoice. It appears somewhere else: every refusal is a person in the campaign who did not see the offer — and, with a hasty retry, a person who will not see it tomorrow either.

The Marketing Messages API, and the end of marketing on the Cloud API

Meta has a separate API for marketing, the Marketing Messages API for WhatsApp, which started out as MM Lite and left beta on 19 November 2025, already under its new name. The difference that matters here is on the Features page: it factors whether a message is high engagement into delivery decisions, and Meta claims “up to 9% more messages” delivered compared with the Cloud API, where message quality does not enter the per-user limit.

The number has context, and Meta provides it in a footnote: an A/B test with roughly 12 million messages from advertisers in India in January 2025, comparing high-engagement messages only. In other words, the new API does not eliminate 131049. The error codes are the same, and the restriction on US numbers applies there too. It improves delivery for what is already relevant; it does not rescue what is not.

The bigger news came out on 13 October 2026, on the Overview page of the same API: the Cloud API is going to stop accepting marketing. Messaging accounts created on or after 13 April 2027 will not be able to send marketing through the Cloud API; those created earlier can continue until 13 October 2027, when sending marketing through the Cloud API starts returning an error. Utility, authentication and service stay on the Cloud API as they are.

For integrators, this is a migration with a deadline — Meta estimates about two weeks for most integrations. Marketing moves to POST /<PHONE_NUMBER_ID>/marketing_messages, which only accepts marketing templates, with product_policy set to CLOUD_API_FALLBACK or STRICT. And Meta asks you to watch reclassified traffic: utility it has recategorised as marketing must go through the new API, so the integration needs to know each template's current category, and the template_category_update webhook exists for that. Whoever leaves it until October 2027 will learn about the deadline from the error.