Rate limits and quality rating: the invisible ceiling every WABA operates under

A phone number doesn't get one send limit, it gets several stacked ones — and one of them isn't set by any config value at all, but by a rolling score Meta computes from how recipients react.

Intermediate

4 min read

Two completely different kinds of limit, easy to conflate

Throughput rate limit  - how fast messages can be sent, second to second
Messaging limit tier   - how many NEW business-initiated conversations
                          can be started per rolling 24 hours

The first is a technical ceiling: a business phone number can send roughly one message every six seconds to the same recipient (about 10/minute, 600/hour) before hitting error code 131056. That's a pacing problem, solvable with a queue and backoff. The second is a business-level ceiling with nothing to do with request speed — it caps how many people a number is allowed to start a conversation with in a day, and it moves based on behavior, not code.

The messaging limit tiers

A new, unverified number starts at a tier allowing roughly 250 business-initiated conversations in a rolling 24-hour window. From there, tiers step up — commonly cited thresholds are 1,000, 10,000, and 100,000 unique conversations per day, with an effectively unlimited tier above that — and Meta raises a number automatically once it has been sending consistently high-quality messages and using a meaningful fraction of its current tier.

250 -> 1,000 -> 10,000 -> 100,000 -> unlimited
        (each step: consistent quality + real utilization of the current tier)

This is why a product's daily outbound volume, not its code, is often the actual bottleneck early on — hitting the tier ceiling looks identical to a bug (sends start failing) but has nothing to fix in the codebase.

Each step up requires the same two things: consistent quality at the current tier, and real utilization of it — Meta raises the ceiling automatically, there's no manual "request a tier increase" button to click.

Quality rating: a score, not a setting

Every phone number carries a quality rating — Green, Yellow, or Red — visible in WhatsApp Manager's phone number panel. It's computed from real recipient signals: message blocks, "report spam," and negative in-app feedback on recent conversations. Nothing about it is configured; it's an outcome, measured continuously against actual traffic.

Green   - healthy, normal sending continues
Yellow  - degraded, worth investigating before it worsens
Red     - the number's messaging limit tier can be downgraded, or
          sending paused, until quality recovers

The compounding trap this creates

The mechanism that catches teams off guard: a quality drop doesn't just sit there as a bad score — it can shrink the messaging limit tier itself, which means fewer conversations can be started, which for a growing product often means falling further behind demand right when volume matters most. A single ill-targeted marketing blast (sent to people who never really opted in, worded aggressively, sent at an odd hour) can drag a number from Green to Red fast enough to visibly cap throughput within the same day.

Bad send batch -> blocks/complaints spike -> quality drops to Yellow/Red
             -> tier may be downgraded -> lower daily send ceiling
             -> even legitimate, wanted messages start queuing or failing

What actually protects it

Quality rating responds to relevance, not just volume: sending only to people who meaningfully opted in, keeping Marketing-category content honestly separate from Utility and Authentication traffic, honoring opt-outs immediately, and not re-sending to numbers that have gone quiet or unresponsive. None of this is enforced by the API at send time — a send call with unhealthy targeting will succeed and return a message ID exactly like a healthy one. The quality consequence shows up later, in the score, not in the response of any individual call.