GLOSSARY

What is a Messaging Limit?

A messaging limit is the cap on how many unique customers a WhatsApp business phone number may start a conversation with in a rolling 24-hour period. Meta assigns it as a tier, raises it automatically when volume and quality justify it, and lowers it when a number stays at a red quality rating.

Try Pinlyx freeSee live demo

Free forever plan · No credit card required · Cancel anytime

Quick definition

A messaging limit is the cap on how many unique customers a WhatsApp business phone number may start a conversation with in a rolling 24-hour period. Meta assigns it as a tier, raises it automatically when volume and quality justify it, and lowers it when a number stays at a red quality rating.

In a single sentence: it counts people you start conversations with, not messages you send.

What it means

A messaging limit is WhatsApp's answer to the question "how much reach has this business earned?" It is expressed as a tier attached to a single business phone number, and it caps the number of unique customers that number may start a conversation with in a rolling 24-hour period.

The unit is the part people get wrong. The limit does not count messages. It counts distinct recipients you initiated with. A support team that exchanges two hundred messages with forty customers has used forty. A marketing team that sends one template each to five thousand people has used five thousand. And a reply inside an open 24-hour customer service window does not count at all, because the customer opened that conversation.

That single design choice tells you what Meta is optimising for. Conversations people asked for are unconstrained. Interruptions are rationed, and the ration grows only as you prove that your interruptions are welcome.

The tiers, and how you climb them

Tiers step up by an order of magnitude at a time, from the starting cap through to unlimited. Meta publishes the ladder and has adjusted it more than once, so treat the exact figures as current policy rather than as constants, and read the tier your number is actually on from the API instead of assuming.

Climbing is automatic and has three conditions that must hold together:

  1. Business verification. The parent Business Portfolio must be verified. Without it you stay at the entry tier no matter how well you behave.
  2. Quality that is not red. A number in trouble does not get promoted, and quality rating is evaluated continuously.
  3. Demonstrated volume. You have to actually use a meaningful proportion of the current tier over a recent period. An idle number never advances.

There is no application, no form and no support ticket that accelerates this. It is the single most common planning failure we see: a team integrates two weeks before Black Friday, sits at the entry tier because nothing has been sent yet, and discovers on the day that reaching their list would take a fortnight. Warming a number takes calendar time, so the integration has to go live long before the campaign that needs it.

Limit is not throughput, and neither is a spam block

Three different constraints produce three different errors, and each needs a different response. Confusing them is why teams "fix" a quality problem by adding retries.

Capacity is the tier: unique recipients per 24 hours. You feel it as the number becoming restricted.

Throughput is requests per second. Cloud API provisions numbers at a default messages-per-second level and can raise it for high-volume senders. Exceed it and you get a standard rate-limit error, which genuinely is retryable with backoff.

Quality enforcement is neither. When previous messages have collected blocks and reports, sends can be refused outright with a spam rate-limit error. It looks like a rate limit and behaves like a penalty. Retrying it in a loop is the exact wrong response, because the sends that succeed keep feeding the problem that caused the restriction.

There is a fourth, narrower control worth knowing: a per-user frequency cap on marketing messages. Meta will decline to deliver an additional marketing message to an individual who has already received too many recently, and the send fails for that person while the rest of the batch goes out normally. It is a quiet cap, it is not something you can raise, and it means the correct strategy for a valuable contact is fewer, better marketing messages rather than more.

Why it matters

The messaging limit is the ceiling on what your channel can be worth. Every campaign forecast that assumes you can reach the whole list tomorrow is wrong unless you have checked the tier first, and every quality incident that costs you a tier costs you reach for far longer than it took to lose it.

The asymmetry is the thing to internalise. A downgrade can happen in a day. Climbing back requires demonstrating volume at a tier you no longer have, which takes weeks. That makes the limit the clearest financial argument for careful list hygiene: it is not about avoiding a telling-off from Meta, it is about not losing an order of magnitude of reach for a quarter.

Real-world examples

  1. The launch that could not launch. A retailer with 60,000 opted-in contacts sat at the 1,000 tier because the number had only been used for order notifications to a few hundred people a day. Reaching the list would have taken two months. The fix was to ramp volume over the preceding quarter, not to send harder in December.
  2. The support desk that never notices. A SaaS company handles thousands of inbound conversations a week and has never come close to its tier, because inbound conversations do not consume it.
  3. The retry loop. An integration treated a spam rate-limit error as transient and retried every thirty seconds. Quality fell further, the tier was downgraded, and the downgrade was blamed on Meta rather than on the loop.
  4. The right way to add a number. A group with three brands runs three numbers, each with its own tier and its own quality history. Capacity scales with the business, and a problem in one brand does not consume another brand's reach.

Common mistakes

  • Counting messages instead of unique recipients. Your capacity model is wrong from the start if you do.
  • Planning a launch without reading the tier. It is one field on the phone number node. Read it before you promise a date.
  • Retrying a spam rate-limit error. That error is a quality signal, not a transient failure.
  • Adding numbers to dodge a cap. Legitimate when the numbers are genuinely different senders, and a pattern Meta acts on when they are not.
  • Firing the whole batch at midnight. Spreading sends across the rolling window means capacity frees up as you go, and it also lands messages at humane local times.
  • Ignoring the DOWNGRADE webhook. Your audience cap changed. Any scheduler that does not recalculate is about to fail the rest of the day's queue.

Related concepts

How Pinlyx handles it

Pinlyx reads the current tier for each connected number, shows how much of the rolling window is already spent, and refuses to queue a campaign whose audience exceeds the capacity that remains. Sends are paced across the window rather than fired in one burst, throughput errors are retried with backoff while quality errors stop the campaign instead, and a DOWNGRADE event recalculates the day's plan automatically. The same pacing engine drives Telegram and X sending, so the operator sees one queue rather than three. More on WhatsApp CRM.

Cheat sheet · the tier ladder

Five steps, each an order of magnitude apart.

Tier names are the values Meta returns in current_limit. Meta adjusts the ladder, so read the live value rather than trusting a number you memorised.

TierWhat it allowsHow you get there
TIER_250Start conversations with up to 250 unique customers per rolling 24 hours. Where unverified accounts sit.The default on a new number. Business verification is the gate to anything above it.
TIER_1KUp to 1,000 unique customers per rolling 24 hours.Verified business, healthy quality, and enough real volume at the tier below.
TIER_10KUp to 10,000 unique customers per rolling 24 hours.Same rule again. The step is automatic once the volume and quality conditions hold.
TIER_100KUp to 100,000 unique customers per rolling 24 hours.The tier where most large senders operate comfortably.
TIER_UNLIMITEDNo cap on unique recipients. Throughput, not the limit, becomes the constraint.Sustained volume at the previous tier with quality that never drops.
Four errors that all look like rate limits

Only one of them should ever be retried.

CodeWhat it really meansCorrect response
130429API throughput rate limit. You are calling the endpoint faster than the number is provisioned to accept.Back off and retry with jitter. This is about requests per second, not about unique recipients.
131048Spam rate limit hit. Sending is restricted because previous messages were blocked or flagged.Stop the campaign. This is a quality problem wearing a rate-limit costume, and retrying makes it worse.
131049Meta declined to deliver this marketing message to protect ecosystem engagement, a per-user frequency cap.Not retryable for this user right now. Reduce marketing frequency per contact and prioritise what matters.
131056Pair rate limit: too many messages between this business number and this one recipient in a short period.Almost always a loop in your own automation. Deduplicate before you retry anything.
Planning a campaign against the tier

Read the capacity, then size the batch.

# The tier change arrives as a webhook, not as a notification email
{
  "field": "phone_number_quality_update",
  "value": {
    "display_phone_number": "905550000000",
    "event": "DOWNGRADE",
    "current_limit": "TIER_1K"
  }
}

// Capacity planning, in plain terms
const TIER_CAPACITY = {
  TIER_250: 250, TIER_1K: 1000, TIER_10K: 10000,
  TIER_100K: 100000, TIER_UNLIMITED: Infinity,
};

function plan(campaign, number) {
  const cap = TIER_CAPACITY[number.currentLimit];
  // Conversations you STARTED in the last 24h, not messages sent.
  const spent = uniqueBusinessInitiatedSince(number, Date.now() - 86400e3);
  const room  = cap - spent;

  if (campaign.audience.length <= room) return sendAll(campaign);

  // Split across days instead of collecting restricted errors.
  return schedule(campaign, { perDay: Math.floor(room * 0.9) });
}

// Retry policy, by error class
const RETRYABLE = new Set([130429]);          // throughput only
const STOP_CAMPAIGN = new Set([131048]);      // quality enforcement
const SKIP_CONTACT = new Set([131049, 131056]); // per-user caps
Scaling checklist

Six rules for growing capacity without losing it.

  • Complete business verification before you need the reach, not during the campaign.
  • Go live with the number weeks early, so real volume accumulates before the big send.
  • Read the current tier from the API at plan time and size the audience against it.
  • Pace sends across the rolling window rather than firing everything at once.
  • Classify every send error: retry throughput, stop on quality, skip per-user caps.
  • Add a second number only when it represents a genuinely different sender.

Messaging limits: FAQ

Capacity questions that decide whether a campaign can actually ship.

Unique customers you start a conversation with in a rolling 24-hour period, not messages. Sending forty messages to one person costs you one against the limit. Sending one message each to forty people costs forty. Replies inside an open customer service window do not consume it either, because the customer started that conversation, not you. This is why a support-heavy number rarely notices its tier while a broadcast-heavy number hits the ceiling constantly.
Meta upgrades automatically. The conditions are that the number is attached to a verified business, that quality rating is not red, and that you have actually used a meaningful share of your current tier over a recent period. There is no application form and no support ticket that speeds it up. Practically it means you cannot jump straight to a big launch: you have to build volume through the tiers first, which is why an integration should go live weeks before the campaign that needs it.
New business-initiated conversations stop being accepted for the rest of the rolling period, while replies inside open windows keep working normally. The number status shows as restricted. Nothing is permanently damaged, and capacity returns as the oldest conversations age out of the 24-hour window, so a queue that spreads sends across the day rather than firing them all at once will often never notice the cap at all.
No, and confusing them sends people down the wrong debugging path. The messaging limit is about how many unique people per day. Throughput is about how many API calls per second the number will accept, which Cloud API provisions at a default level and can raise for high-volume senders. A 130429 error is a throughput problem, solved by pacing and retries. Hitting the tier is a capacity problem, solved by verification, quality and time.
Per phone number. Each number in a WABA carries its own tier, and a busy number can be restricted while a sibling sits idle at the same tier. That makes adding a second number a legitimate scaling strategy, with one caveat: it is only legitimate when the numbers represent genuinely different senders, such as different brands, regions or departments. Spinning up numbers purely to evade a cap on a list that is generating complaints is the pattern Meta enforces against.
Yes. A number that stays at a red quality rating through the recovery period is downgraded a tier, and the downgrade arrives on the phone_number_quality_update webhook as a DOWNGRADE event with the new current_limit. Recovery back up is not instant either, because climbing a tier requires demonstrating volume at the tier you just lost. That asymmetry is the real cost of a bad campaign: the loss is quick and the recovery is slow.

Keep reading

Quality rating

The score that raises or lowers your tier.

24-hour customer service window

Inbound conversations that never consume the limit.

Message template

What you actually spend the capacity on.

Flood wait

The equivalent throttling signal on Telegram.

Drip campaign

Sequences paced around a cap instead of against it.

WhatsApp CRM

Capacity-aware queueing across every connected number.

Ready to ship

Plan campaigns against real capacity.

Pinlyx reads your tier, shows what is left in the rolling window, and paces the queue so a campaign never collects restricted errors.

Start freeTalk to sales

Free forever plan · GDPR-ready · No credit card required

We value your privacy

We use cookies to improve our site, analyze traffic, and personalize ads. You can accept all, reject non-essential, or customize your choices. Read our Cookie Policy.