Why your WhatsApp messages aren't landing: the EC_FREQUENCY_CAPPING guide

Your WhatsApp sequence was working. One day, without changing anything, a chunk of your messages stops getting delivered. No blocked number, no drained balance, the contact simply never receives them. Look closely at the delivery reports and an unfriendly code shows up: EC_FREQUENCY_CAPPING. This is the guide we wish we'd had the first time we hit it in production.

Frequency capping is a limit Meta applies per USER: how many marketing messages a single person can receive within a time window (a roughly rolling 24 hours, though Meta doesn't publish the exact number and tunes it dynamically). When your business tries to send a marketing message to someone who's already hit their quota, Meta accepts the request but does NOT deliver the message, and returns EC_FREQUENCY_CAPPING in the delivery report.

WhatsApp was built on a promise: it's people's private channel, not a spam inbox. When Meta opened the door to WhatsApp marketing, it knew that if inboxes filled up with unsolicited promotions, users would abandon the channel. Frequency capping is how it protects that promise: it caps how many different brands can bombard the same person with marketing, no matter how much you're willing to pay to send.

In other words, the cap isn't punishing your account for doing something wrong. It's throttling the marketing volume that contact has ALREADY received across the whole ecosystem. You can be the polite third sender to a user who already got promos from five other brands today, and yours is the one that drops.

Outside the 24-hour window (we'll get there), any message your business initiates has to be an approved template, and every template belongs to a category. The category is what determines whether the frequency cap applies to you:

• MARKETING: promotions, offers, invitations, re-engagement, anything whose goal is to sell or spark interest. This IS the category that suffers frequency capping. Most cold outreach lives here.
• UTILITY: transactional messages about something the user already started or expects: order confirmation, appointment reminder, status update, payment notice. The marketing frequency cap does NOT apply (though it must map to a real interaction or agreement).
• AUTHENTICATION: one-time passcodes (OTP) for identity verification only. Its own category, its own rules, outside the reach of the marketing cap.

Before you rewrite anything, confirm the problem is frequency capping and not something else. Signs that point to this error rather than a blocked number or missing balance:

1. The send is accepted (2xx) but the later delivery report marks the message failed with EC_FREQUENCY_CAPPING or an equivalent frequency status.
2. It fails intermittently, not entirely: some contacts receive and others don't, with no number or country pattern.
3. It gets worse when you tighten cadence: if your follow-ups go out at +5 min and +10 min, almost all drop; if they're days apart, almost none do.
4. They're MARKETING-category templates. The UTILITY ones in the same flow keep getting delivered.

Once confirmed, these are the practices that keep your sequences delivering:

• Categorize correctly by design. If a message truly is transactional (a confirmation, reminder, or update the user expects), phrase it and declare it as UTILITY. Don't slip a sales hook into a utility message — that's exactly what gets Meta to recategorize it to marketing.
• Space out marketing follow-ups. As a rule of thumb, leave at least 24 hours between consecutive marketing templates to the same contact, and no sooner than 24 hours after the first send. The +5 min / +10 min cadence is the fastest route to the cap.
• Pace your retries. If a message drops for frequency, retrying it immediately drops again. Apply backoff (e.g. 24 hours) before retrying that contact.
• Don't treat a frequency failure as a hard bounce. The contact is valid; don't suppress them. They were just saturated that day.
• Measure in the delivery report, not the send code. Your real delivery rate lives in the asynchronous callbacks.

Here's the part that changes the game. When a user messages you, a 24-hour service window opens. Inside that window you can reply with free-form messages (no template) and those messages are NOT subject to marketing frequency capping. Meaning: if your outreach gets the contact to reply even once, you go from fighting the cap to conversing freely for 24 hours.

The strategic consequence is huge: the goal of the first touch isn't to sell, it's to earn a reply that opens the window. Everything after that happens on ground where the cap doesn't apply. A good conversational agent is designed for exactly this: opening and sustaining the window with relevant messages, not burning marketing templates against a wall.

EC_FREQUENCY_CAPPING isn't a punishment on your account or a balance problem: it's Meta protecting the user's inbox from marketing overload. You diagnose it in the delivery report, you mitigate it by categorizing templates well and spacing cadence, and you avoid it entirely when you earn a reply and converse inside the 24-hour window. Whoever understands this doesn't just stop losing messages — they build an outreach operation that takes the volume without shutting itself off.