WhatsApp API Throughput: 80 mps, 1,000 mps and Rate Limits

It's the first hour of a sale. Order confirmations are queuing faster than ever, and the Cloud API starts answering with error 130429. Meanwhile your support bot, replying to the same shoppers, is getting 131056 on every third message. Both are WhatsApp API throughput limits, and they are not the same limit.

Throughput is how fast you can push messages through one business phone number. It sits alongside, not inside, the messaging limit that caps how many people you can reach in a day. Meta also applies a separate per-recipient speed limit and ordinary Graph API call quotas.

This guide covers the numbers as of October 2026, how the free upgrade to 1,000 messages per second works, what each error means and how to build a sender that doesn't trip them.

The numbers that matter

Here is every speed-related cap on the Cloud API, from Meta's throughput and platform rate limits pages.

Two details catch teams out. Throughput counts inbound messages too, so a busy support number has less headroom for outbound bursts. And if you run WhatsApp coexistence, the 20 mps cap is fixed for as long as the number stays on both the app and the API.

Put 80 mps in perspective: that's 4,800 messages a minute from one number. For most businesses the WhatsApp API messaging limits, which cap unique people reached outside service windows per day, bind long before raw speed does.

Getting to 1,000 messages per second

Meta upgrades a number to 1,000 mps automatically, for free and with no change to pricing, when all three conditions hold:

1. The business portfolio has an unlimited messaging limit.
2. The number has messaged 100,000 or more unique users outside customer service windows in a moving 24 hours.
3. The number's quality is YELLOW (Medium) or better. See how the WhatsApp quality rating works.

The upgrade takes up to a minute, during which the number can't be used and requests return 131057 (business account in maintenance mode). Once upgraded, later increases happen without downtime. Meta announces it with a phone_number_quality_update webhook whose event is THROUGHPUT_UPGRADE.

Check the current level any time. Use the current Graph API version from Meta's changelog in place of v23.0:

curl "https://graph.facebook.com/v23.0/PHONE_NUMBER_ID?fields=throughput" \
  -H "Authorization: Bearer $WHATSAPP_TOKEN"

Because condition two requires a six-figure daily audience, the upgrade is realistic only for the largest senders. If you are near it, make sure your retry logic tolerates a minute of 131057 mid-campaign.

Pair rate limits: the one that bites chatbots

The pair rate limit governs how fast one business number can message one user. Meta's figure is 1 message every 6 seconds, about 10 a minute or 600 an hour. You can burst up to 45 messages in 6 seconds, but a burst borrows from future quota: afterwards you wait as long as those messages would have taken at the normal rate. Meta's own example is that a burst of 20 needs about a 2-minute pause before the next message to that user.

This is why bots trip it. A flow that sends a greeting, an image, a product list and a question in quick succession uses a 4-message burst, then owes about 24 seconds before it can say anything else to that person. If the user replies instantly and the bot fires another burst, 131056 follows.

Fixes are mostly design, not infrastructure:

• Combine messages. One message with a caption beats an image followed by a text.
• Wait for the user. Let replies drive the pace rather than pushing several prompts in a row.
• Retry only the pair. Meta says other recipients are unaffected, so park the user's queue and keep serving everyone else. Meta suggests retrying after 4 to the power of X seconds, starting at X = 0 and adding 1 after each failure.

What each error means

That last row matters. 131048 looks like throttling but comes from quality, and retrying harder makes it worse. Our reference to WhatsApp API error codes covers the rest.

Building a sender that respects the limits

The pattern is a queue per phone number, a steady rate under the cap, spacing per recipient and retries only for retryable codes. A compact Node.js version:

const GRAPH = "https://graph.facebook.com/v23.0";
const MPS = 60;                // stay under the 80 mps default
const PAIR_GAP_MS = 6000;      // 1 message every 6 s per recipient
const RETRYABLE = new Set([130429, 131056, 131057]);
const lastSentTo = new Map();  // recipient id -> last send time
const sleep = (ms) => new Promise((r) => setTimeout(r, ms));

async function sendOnce(phoneNumberId, payload) {
  const res = await fetch(`${GRAPH}/${phoneNumberId}/messages`, {
    method: "POST",
    headers: {
      Authorization: `Bearer ${process.env.WHATSAPP_TOKEN}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify(payload),
  });
  const body = await res.json();
  return { ok: res.ok, code: body.error?.code, body };
}

async function sendWithBackoff(phoneNumberId, payload, maxTries = 5) {
  for (let x = 0; x < maxTries; x++) {
    const { ok, code, body } = await sendOnce(phoneNumberId, payload);
    if (ok) return body;
    if (!RETRYABLE.has(code)) throw new Error(JSON.stringify(body.error));
    await sleep(4 ** x * 1000); // 1 s, 4 s, 16 s, 64 s, 256 s
  }
  throw new Error("retries exhausted");
}

async function drain(queue, phoneNumberId) {
  const tick = 1000 / MPS;
  while (queue.length) {
    const job = queue.shift();
    const wait = (lastSentTo.get(job.to) ?? 0) + PAIR_GAP_MS - Date.now();
    if (wait > 0) { queue.push(job); await sleep(tick); continue; } // serve someone else first
    lastSentTo.set(job.to, Date.now());
    sendWithBackoff(phoneNumberId, job.payload).catch((e) => job.onError?.(e));
    await sleep(tick);
  }
}

In production, put this behind a real job queue (BullMQ, SQS, Cloud Tasks) with one rate limiter per phone number, since all workers share the number's budget. Retrying on the codes above is safe because Meta rejected the request. Retrying after a timeout is not: the first attempt may have gone through. Record the outcome and check status webhooks before resending, as explained in our guide to preventing duplicate WhatsApp API messages.

Your webhooks need throughput too

Every message you send produces status webhooks (sent, delivered, read), and replies arrive the same way. Meta asks that your webhook servers handle 3 times your outgoing message rate plus 1 times expected incoming traffic. Its example: at 1,000 mps with a 30% response rate, plan for 3,000 status webhooks plus 300 incoming messages per second. Latency targets are a median at or under 250 ms, with fewer than 1% of requests over 1 second.

Practical consequences:

• Acknowledge first, process later. Return 200, push the payload to a queue, then do the work.
• Expect duplicates. Meta retries failed deliveries for up to 7 days with exponential backoff, so dedupe on message ID plus status.
• Use media IDs for big sends. Meta recommends uploading media once and sending the media ID instead of a URL on your own server, or using HTTP caching if you must self-host.

For the platform overview, see the complete guide to the WhatsApp API.

Where Tenashi fits

If you need OTPs in seconds, flash-sale confirmations at scale or thousands of messages a minute, use Meta's Cloud API directly or through a provider. Tenashi is not built for that, on purpose.

Tenashi is a shared WhatsApp inbox and CRM that runs on the number you already use, linked by QR scan rather than through the official API. Its developer API sends from your team's real number and paces every send: one message every 4 to 12 seconds per number, so a batch of 100 takes about 10 minutes and nothing is dropped. Keys are limited to 120 requests a minute, with a 429 rate_limited and a Retry-After header when you exceed it. That pace protects the number your business depends on, though WhatsApp can still ban numbers that spam. It suits reminders, follow-ups and messages into existing DMs and groups, where everything sent also shows up in the team inbox. Plans start from $18/mo.

Read the API docs · Get started

FAQ

What is the default WhatsApp API throughput?

Each registered business phone number on Cloud API supports up to 80 messages per second by default, counting inbound and outbound messages of all types. Numbers used with both the WhatsApp Business app and Cloud API through coexistence are fixed at 20 messages per second. Eligible high-volume numbers are upgraded to 1,000 messages per second automatically.

How do I get 1,000 messages per second on WhatsApp?

You can't request it; Meta upgrades eligible numbers automatically and free. The business portfolio needs an unlimited messaging limit, the number must message at least 100,000 unique users outside service windows in a moving 24 hours, and its quality must be yellow or better. The upgrade takes up to a minute.

What does WhatsApp error 131056 mean?

Error 131056 is the pair rate limit: too many messages from one business number to the same user in a short time. Meta allows one message every 6 seconds per user, with bursts of up to 45 that must be paid back. Wait and retry that recipient only; messages to other users aren't affected.

What does WhatsApp error 130429 mean?

Error 130429 means the phone number exceeded its throughput, normally 80 messages per second including inbound traffic. The API keeps returning it until you're back under the level. Slow your send rate, retry with backoff and share one rate limiter across every worker that sends from that number, since they all draw on the same budget.

Does higher WhatsApp throughput cost extra?

No. Meta states that the upgrade to 1,000 messages per second is free and doesn't change pricing. You still pay the normal per-message rates for marketing, utility, authentication and service messages, based on each recipient's country. Your provider, if you use one, may bill its own platform fees on top.

---

Speed limits are easy to respect once you queue per number and space messages per person. If your WhatsApp work is mostly conversations rather than floods, see how Tenashi handles it on the number you already have.