On this page
Error 131049 means WhatsApp withheld a marketing message to protect the recipient, not because anything is wrong with your account, number or template. It is Meta's own per-user cap on how much marketing a person can receive from every business combined, and the only real fix is to wait and switch to a UTILITY template for anything transactional.
Symptom
A recipient row on a broadcast, sequence step or automation rule shows Failed or Suppressed, and the error text reads something close to Meta's own title for this code: "This message was not delivered to maintain healthy ecosystem engagement." Inside VGraple CRM the same event is translated to plain language: "Meta paused marketing messages to this recipient (per-user frequency cap, error 131049). Retrying within 24 hours will fail again. Use a UTILITY-category template for transactional alerts, utility templates are exempt from this cap." If you attempt to send the same recipient another marketing template within a day, the campaign shows them as suppressed before the send is even attempted, with the reason naming how many hours ago the first 131049 happened.
Why it happens
Meta enforces a "healthy ecosystem engagement" limit at the recipient level: it tracks, across every business sending that person WhatsApp marketing, how much volume they have received recently, and refuses further MARKETING-category templates once that person's own personal cap is reached. It has nothing to do with your account history, your number's quality rating, or your plan on VGraple CRM. A recipient who follows several D2C brands, salons or coaching institutes on WhatsApp can hit this cap purely from other businesses messaging them, and there is no dashboard, even on Meta's side, that tells any individual business where a given recipient's cap currently sits.
The cap applies only to the MARKETING category. UTILITY templates (order updates, appointment reminders, delivery confirmations) and AUTHENTICATION templates (OTPs) are explicitly exempt, because Meta's own policy defines them as content the customer is already expecting as part of a transaction they started.
Fix
- Do not resend the same recipient a marketing template immediately. Meta's own guidance, mirrored in
MARKETING_CAP_SUPPRESSION_HOURSin VGraple CRM's delivery logic, is that a retry inside 24 hours of a 131049 is guaranteed to fail again. - Check if the message was genuinely transactional. If it was an order update, a booking confirmation, or anything the customer directly triggered, resubmit the template as UTILITY category instead of MARKETING; UTILITY sends are exempt from this cap entirely. See template categories and pricing for the boundary between the two.
- Wait at least 24 hours before trying a marketing send to this recipient again. There is no guarantee the cap has lifted for them specifically, since it depends on messages from other businesses too, but 24 hours is the shortest interval Meta's own guidance treats as worth retrying.
- Narrow future audiences to recently engaged contacts. A recipient who has replied, clicked or interacted with your business recently is statistically far less likely to be near their cap than a cold contact being blasted by several businesses at once.
- If it keeps happening to the same segment, reduce marketing frequency to that list. Two marketing broadcasts to the same audience within a short window compounds the chance of hitting this cap on the second one, independent of anything else you change.
How VGraple CRM handles it automatically
The moment a send fails with 131049, VGraple CRM records the exact error code and timestamp against that contact. Every subsequent MARKETING-category send, whether from a broadcast, a sequence step, or an automation rule, checks for a 131049 in the last 24 hours before attempting delivery; if one is found, the send is skipped before it ever reaches Meta, with the reason shown as "Skipped: Meta is limiting marketing messages to this recipient (error 131049, [n]h ago). Wait at least 24 hours or use a UTILITY-category template." This is deliberate: since 30 April 2026, Meta applies retry penalties at the WhatsApp Business Account level for businesses that keep re-attempting sends it has already refused, so a naive resend loop damages the whole account, not just that one message.
Suppressed recipients from a 131049 cap are never counted in the campaign's failed total the way a genuine delivery problem would be, and they are structurally excluded from "Retry failed," which cannot pick up a suppressed row by design. UTILITY and AUTHENTICATION sends to the same contact are entirely unaffected by this check, since the underlying block on VGraple CRM's side only ever applies to the MARKETING category.
Example
A coaching institute sends a marketing broadcast to 2,000 leads about a new batch starting. 140 recipients come back with 131049, most of them people who also get marketing WhatsApp messages from two or three other local businesses. None of the 140 are billed. Two days later the institute sends a UTILITY template confirming enrolment to a subset of those same 140 who actually signed up, and it goes through immediately, since UTILITY was never affected by the marketing cap.
Prevention
The single most effective prevention is category discipline: never submit a genuinely transactional message as MARKETING just because it is easier to write without Meta's stricter utility review. See template rejected: reasons and fixes if a utility resubmission gets bounced for reading too promotionally. Beyond that, spacing marketing sends to the same audience by more than a day, and preferring segments of contacts who have engaged in the last two to four weeks over your full contact list, both reduce how often any given recipient is near their personal cap when your message arrives. VGraple CRM's own marketing frequency cap setting lets you enforce wider spacing between your own marketing sends to the same list than Meta's minimum, which is worth tightening if your audience tends to follow several WhatsApp businesses at once.
What this is not
131049 is frequently confused with a quality rating problem or a sign that a number is at risk, and it is neither. Your number's GREEN, YELLOW or RED quality rating is a property of how recipients react to messages from your number specifically, tracked over a rolling 7-day window; 131049 is a separate, per-recipient system that applies identically regardless of your number's own standing. It is also not the same as error 131050, which means this specific recipient tapped "stop marketing messages" for your business, a deliberate, per-business opt-out rather than a shared, adaptive cap; 131050 carries a much longer, 30-day suppression window on VGraple CRM's side because it reflects an intentional choice by the recipient rather than a volume ceiling. Neither error affects a number's throughput or pacing rate the way a throughput error (130429) or a spam-rate restriction (131048) does.