WhatsApp Cloud API rate limits and throughput, in plain numbers

A client messaged me last month with a screenshot of a failed campaign: 4,000 recipients, 1,100 delivered, 2,900 errors. Their first assumption was that they had hit their daily messaging limit. They had not. They had 40,000 left on it.

What they hit was a rate limit, which is a different thing in a different unit, and it fails in a way that looks like a message problem until you read the error code. If you are about to send anything at volume on the WhatsApp Business Platform, this is the piece of arithmetic worth understanding before your first big send rather than after.

Three ceilings, three different units

Almost every confused conversation about WhatsApp limits comes from mixing these up. They do not stack neatly, and fixing one does nothing for the others.

The messaging limit is the one everybody knows about — I covered the portfolio tiers and how they grow in WhatsApp messaging limits. Today's post is about the middle row, because it is the one that breaks a working integration on a launch day.

What "80 messages per second" actually means

At the time of writing, the documented default throughput on the Cloud API is in the region of 80 messages per second per business phone number, with a much higher ceiling available on request for accounts that need it. Treat that figure as a starting point to verify in your own dashboard, not a constant — Meta has changed how throughput is calculated more than once, and the number you should design for is the one your app is currently allowed.

Two details matter more than the number itself:

It is per second, and it is short-term. You can be far under your daily ceiling and still get throttled at 10:00am because you fired 5,000 HTTP requests in a tight loop. The daily limit never sees it. The rate limiter does, immediately.

It is per number, not per account. Two numbers do not double your throughput automatically in a way you can rely on if both are sending from the same server at the same instant. Build the pacing per number, then reason about the total.

There is also a smaller, less obvious ceiling: the number of requests in flight at once. A sender that opens 200 concurrent connections will trip limits that a sender with 8 workers never touches, even when both send the same 5,000 messages.

The error codes that mean "slow down"

Most throttling arrives as a normal HTTP error inside a 200-shaped payload or a 400 response, which is why people read it as a message failure. The ones worth memorising:

• 429 Too Many Requests — the blunt one. No message was created; retry later.
• 130429 — Cloud API message throughput rate limit hit. You are sending faster than the number allows. Nothing is wrong with your template or your recipient.
• 131048 — spam rate limit hit. This is not throughput. This is the platform telling you your content is being reported, and it needs a different response: stop, look at the list, look at the offer.
• 131056 — pair rate limit hit, usually two endpoints hammering each other rather than one sender going too fast.
• 131026 — message undeliverable. Not a rate limit at all, but it arrives in the same batch of failures and people miscount it as one.

The distinction between 130429 and 131048 is the difference between "add a queue" and "stop and think". Retrying a 131048 makes it worse. I wrote more about the error vocabulary in WhatsApp Business API errors and what they mean, and it is worth reading the two side by side.

A worked example, because this is the part that surprises people

Say you have 20,000 recipients and an 80 messages-per-second allowance. The naive calculation is 250 seconds, about four minutes. The real send takes closer to twenty.

Why: every message is at least one HTTP request, media templates add an upload and a send, each failure costs a retry with a backoff, and your own database writes and webhook processing sit between the steps. A sender paced at 80 requests per second of attempts delivers far fewer than 80 messages per second once anything goes wrong. Design for half your allowance and you will finish in a predictable window instead of discovering the wall at 60% of the list.

This is also why "just send it all in one batch" is not a thing. There is no bulk endpoint that takes an array of 20,000 recipients and returns when they are done.

How to build a sender that stays under the cap

Four changes cover almost all of it, and none of them are exotic:

1. Put a queue between your database and the API. Enqueue rows, then a worker pulls at a fixed rate. The queue is the thing that makes the send resumable when your process restarts at 2am.
2. Pace with a token bucket, not a sleep. A token bucket lets you burst a little and then holds steady, which matches how the limiter behaves. A fixed sleep(0.0125) per message drifts and stalls on any latency.
3. Cap concurrency at something small — 8 to 16 workers. More workers do not send faster once you are rate limited; they just generate more 429s and more retries, which consume the allowance you were trying to preserve.
4. Retry only what is retryable, with exponential backoff and jitter. Retry 429 and 5xx. Do not retry 131048. Do not retry a validation error. And record a per-message id so a retry cannot produce a duplicate — duplicate sends are the one failure that also costs you money and a block.

If you want the single highest-leverage line of code in the whole sender, it is the one that decides a failure is not worth retrying. Unlimited retries on a hard error will burn your rate limit on messages that can never succeed.

Where it breaks in production

Three things I have watched go wrong, all of them invisible in a test run:

• The retry storm. One bad template version starts failing fast, every worker retries, and the retry traffic pushes you into 429 territory for the messages that were fine. Give each class of error its own queue, or at minimum its own backoff.
• Media. Sending a PDF or an image to 5,000 people is not 5,000 API calls, it is 5,000 calls plus network time for uploads and downloads. Media-heavy campaigns are much slower per message than a text template, and the pacing that works for text will overrun for a catalogue send.
• The 24-hour window. If a send crosses the window boundary for a segment of recipients, some messages switch from free-form to template and start failing for a completely non-rate reason. Check window state per recipient at dequeue time, not when you built the list.

Where this sits in the bigger picture

Rate limits are a plumbing problem, and plumbing problems are the cheapest ones to solve — they are deterministic, testable, and they do not depend on how your customer feels. If your campaign failed today, before you rewrite anything, look at the error distribution. A wall of 130429 is a queue you have not built. A wall of 131048 is a list you should not be messaging. Those two fixes have nothing in common and only one of them is code.

BNex runs on the official WhatsApp Business Platform and keeps your templates, contacts and conversations in one place, so the sending side is not something you assemble from scratch. If you are still at the setup stage, the Cloud API setup walkthrough covers the parts that come before this one — phone number, app, token, first test message — and the pricing guide explains why conversation categories change what a slow campaign costs you.

If you are mid-build and hitting 429s you cannot explain, message me on WhatsApp with your error codes and the rate you are sending at. I have debugged enough of these to tell you in a few minutes whether it is pacing or something else.

Related Reading