Your WhatsApp Business account looks healthy. The quality rating is green, your messaging tier has room, every template is approved — and yet part of your marketing broadcast comes back failed with error 131049. Nothing you check explains it, because the limit that blocked those messages does not belong to you at all.
What error 131049 actually means
Meta's official error-code documentation describes 131049 in one line:
In plain terms: WhatsApp decided the recipient has received enough marketing recently — from all businesses combined, not just yours — and withheld your marketing template to protect their inbox. This is the per-user marketing frequency cap, and it is a completely separate delivery ceiling from the two most teams already know about.
The three delivery ceilings — and why teams confuse them
1. Messaging limits
How many business-initiated conversations your account can open in a rolling period. Account-level, and it scales. Covered in our guide to WhatsApp Business API messaging limits.
2. Quality rating
How recipients react to your messages — blocks and reports lower it, and a low rating restricts you. Explained in our quality rating guide.
3. Per-user marketing cap
How much marketing the recipient can absorb from every business combined. You cannot see it, and your account health has no influence on it. This is error 131049.
Because the first two are the familiar ones, most teams that see falling delivery rates start auditing their own account — and find nothing wrong. That misdiagnosis costs weeks.
How the per-user cap works (per Meta's documentation)
Meta's per-user marketing template limit documentation confirms the mechanics that make this error so counter-intuitive:
It is adaptive, not fixed
WhatsApp adjusts each user's limit based on their recent marketing message read rate and how full their inbox is with messages from friends, family, and businesses. Meta publishes no fixed number.
The limit belongs to the recipient
A contact can already be at their cap from marketing sent by other businesses. Your very first message to a brand-new contact can fail with 131049.
Only marketing templates count
The cap applies to marketing template messages. Utility, authentication, and service conversations are not part of this limit.
Replies open an exemption
If a user responds, a 24-hour customer service window starts — marketing messages sent inside that window do not count toward the cap and deliver normally.
Regional differences most dashboards don't surface
As of Meta's current documentation: per-user marketing limits are not active for messages sent from business numbers in, or to users in, the European Economic Area, the United Kingdom, Japan, or South Korea. Separately, WhatsApp currently does not deliver marketing template messages to users with United States phone numbers at all. If your audience spans these regions, your delivery data is a mix of different regimes — averaging it hides what is actually happening.
The retry trap that makes it worse
This is exactly where automated broadcast tools and SaaS messaging platforms get hurt. A scheduler that treats a failed webhook status as “retry in 30 minutes” converts one capped message into a day-long delivery freeze for that contact — multiplied across the whole capped segment.
Where diagnosing this gets genuinely difficult
Reading one error code is easy. Untangling a real delivery drop is not, because 131049 rarely arrives alone. A falling delivery rate usually mixes per-user capping with neighbouring failure codes that each demand a different response — 131050 (this user opted out of your marketing — never resend), 131026 (undeliverable for other reasons), tier ceilings, and paused or rejected templates. Retry logic that is correct for one code is actively harmful for another. Multi-tenant platforms sending on behalf of many client WABAs have it hardest: the same broadcast can fail for four different reasons across four client accounts.
How we approach a 131049 delivery audit
- 1
Error-code triage. Separate 131049 from 131050, 131026, throughput and tier errors in your webhook logs, so each failure class gets the correct handling instead of one blanket retry rule.
- 2
Ceiling diagnosis. Establish which of the three delivery ceilings is actually constraining you — account tier, quality rating, or per-user capping — using account signals, not guesswork.
- 3
Send-strategy redesign. Restructure campaigns around engagement: segmentation by recent read behaviour, pacing, and correct use of the 24-hour response window so high-intent contacts are reached inside the exemption.
- 4
Template and category review. Confirm message categories are correct and marketing content is engineered for reads and replies — the exact signals the adaptive cap responds to.
- 5
Monitoring that prevents relapse. Webhook-level failure tracking with per-code alerting, so capping trends are visible before they show up as a revenue problem.
Common mistakes we keep seeing
Instant automated retries
Turns a soft per-user cap into a hard 24-hour block and corrupts delivery metrics.
Blaming the quality rating
Teams pause campaigns and rewrite templates when their account was never the problem.
Treating 131049 like 131050
One is a temporary cap, the other is a user opt-out. Resending to opted-out users damages trust and wastes sends.
Ignoring regional splits
Mixing EEA/UK (no cap) and US (no marketing delivery) traffic into one dashboard average hides the real pattern.
Falling delivery rates on a healthy account?
If approved marketing templates are failing with 131049 while your tier and quality look fine, the fix is not another retry loop — it is a proper delivery audit and a send strategy built around how Meta's adaptive capping actually behaves. We provide WhatsApp Business API delivery audits, error-code triage, and policy-aligned send-strategy support for businesses and SaaS messaging platforms. Reach out via the contact options below and we will review your delivery data before anything else.