WhatsApp error 130429 (rate limit hit): why Cloud API throughput runs out and how to pace sends

WhatsApp error 130429 is a speed problem, not a permission problem. Meta's error codes page lists it under throttling errors with the description "Cloud API message throughput has been reached" and the solution: "The app has reached the API's throughput limit. See Throughput. Try again later or reduce the frequency with which the app sends messages." In other words, your code pushed more messages per second through one business phone number than Meta accepts. Nothing is wrong with the template, the recipient or the account, and the same messages will go through once you send them at a steadier pace.

What throughput means on the Cloud API

Throughput is the number of messages per second (mps) a single business phone number can send, counting both template and free-form messages. Meta's throughput page sets it like this:

Two points trip up developers. First, the ceiling belongs to the phone number, not to your app or server: three workers sending from the same number share one budget. Second, throughput is a separate idea from the messaging limit, which caps how many unique customers you can start conversations with in a rolling 24 hours (250, 2,000, 10,000, 100,000 or unlimited). You can be far below your daily tier and still hit 130429 if you send 2,000 messages in two seconds.

Why it happens

• Unthrottled broadcast loops. A script reads a contact list and calls /messages in a Promise.all over 5,000 rows. The first burst exceeds 80 mps within a fraction of a second.
• Several systems on one number. A CRM, an ecommerce plugin and a chatbot all send from the same number, each pacing itself correctly but together going over the ceiling.
• Retry storms. A failure triggers immediate retries from every worker at once, which makes the next second even busier.
• Coexistence numbers. A number shared with the WhatsApp Business app is capped at 20 mps, so code tuned for 80 mps fails on it.
• Big scheduled sends at round times. Every campaign in a panel set for exactly 10:00 am leaves the number at the same moment.

What the error looks like

130429 normally comes back straight away in the API response, with no message ID. The message text and trace ID below are illustrative:

{
  "error": {
    "message": "(#130429) Rate limit hit",
    "type": "OAuthException",
    "code": 130429,
    "error_data": {
      "messaging_product": "whatsapp",
      "details": "Cloud API message throughput has been reached."
    },
    "fbtrace_id": "Ab3kX9qLmT2vW7yZpR1sQ4e"
  }
}

Because there is no message ID, nothing was sent and nothing was charged. That makes 130429 one of the few send errors where a straightforward retry is correct.

Step-by-step fix

1. Stop the burst. Pause the job that is sending, so failures do not pile up.
2. Find every sender on the number. List each integration, bot and panel that calls /messages for that phone number ID. Their combined rate is what Meta sees.
3. Put sends behind one queue per number. A single queue (Redis, a database table or a job runner) with a fixed rate is the cleanest fix. Start well under the ceiling, for example 40 to 60 mps on a standard number and 10 to 15 on a coexistence number.
4. Retry 130429 with exponential back-off and jitter. Wait about half a second, then one, two, four seconds, adding a random part so workers do not retry together. Cap the wait and the number of attempts.
5. Keep the original order where it matters. Requeue the failed message near the front, so a customer does not get message 2 before message 1.
6. Watch the rate, not just the errors. Log sends per second per number; if 130429 keeps returning at your chosen rate, lower it.

A small, illustrative pacing loop:

const RATE_PER_SEC = 50; // stay below the number's ceiling
const GAP_MS = 1000 / RATE_PER_SEC;

async function sendAll(jobs: Job[]) {
  for (const job of jobs) {
    await sendWithBackoff(job);
    await sleep(GAP_MS);
  }
}

async function sendWithBackoff(job: Job, attempt = 0): Promise<void> {
  const res = await postMessage(job);
  if (res.error?.code !== 130429 || attempt >= 5) return handle(res);
  const exp = Math.min(8000, 500 * 2 ** attempt);
  await sleep(exp / 2 + Math.random() * (exp / 2));
  return sendWithBackoff(job, attempt + 1);
}

130429 and the other rate limits

If the code is 131056, slowing the whole number down will not help; you need to space out messages to that one person. If it is 131048, the cause is blocks and reports, covered in quality rating and messaging limits.

A worked example

Meera manages WhatsApp for Rangoli Home, a home decor store in Jaipur. On the Saturday before Diwali she triggers a utility template, "Your order is packed", for 3,600 orders from a script her developer wrote. The script sends all of them in parallel. About 3,100 calls fail within two seconds with 130429 (illustrative numbers), and the rest go through.

Her developer changes the script to send through one queue at 50 messages per second, with back-off on 130429. The 3,100 messages now take about a minute to leave. Because the failed calls returned no message ID, there were no duplicates to clean up and no charges for the rejected attempts. The number's messaging limit and quality rating are untouched, because neither had anything to do with it.

Preventing 130429

• One sender, one rate per number. Route every integration through the same queue, or give each one a share of the budget.
• Stagger scheduled campaigns by a few minutes instead of starting them all at the same second.
• Plan for coexistence. If a number also runs on the Business app, budget for 20 mps.
• Treat 130429 as retryable but not as normal. A handful during a large send is fine; constant 130429s mean your rate is too high.
• Avoid retry storms. Jitter is not optional when more than one worker retries.

How Broadchat handles 130429

Broadchat's Meta client treats 130429 as a rate-limit rejection: the request was not processed, so it retries it after an exponential back-off with jitter instead of marking the message failed. Campaigns are paced as they send. If Meta keeps rejecting after those retries, the recipient is kept to try again later rather than counted as failed, the current run stops with the note "Meta rate limit reached — the campaign continues on the next run.", and the campaign resumes on its next run. You do not need to re-upload the list or relaunch the campaign.

For other codes, see the WhatsApp API error codes cheat-sheet; for the platform basics, the plain-English guide to the WhatsApp Business API. Agencies running large client broadcasts can offer paced WhatsApp broadcasts under their own brand through the white-label program.