Skip to content

Error 130429 (Rate Limit Hit)

Error 130429 means a business phone number tried to send faster than its Cloud API throughput allows, which is up to 80 messages per second by default.

Also called: Error 130429 · Rate limit hit · Cloud API throughput error

Reviewed

Interactive lab

Hands on: use the controls to explore. Anything that plays on its own pauses while you are working inside it.

Push a broadcast past 80 messages per second

40× slow motionService time S = 100 ms per job on average · 8 workers

Queue diagram: 24 messages waiting, 8 of 8 workers busy, 8 done.

Backlog
∞
grows without bound
Throughput
80/s
ceiling 80/s with 8 workers
Average wait
∞
keeps growing
Utilisation ρ
1.25
≈ 8 of 8 busy
100 messages/s
8

ρ = λ × S ÷ c = 100/s × 100 ms ÷ 8 = 1.25

Backlog grows without bound. ρ = 1.25 ≥ 1: messages arrive faster than 8 workers can finish them. Add workers, speed up each job or slow the producer.
Eight send slots of 100 ms each give one number 80 messages per second. At 100 sends per second the backlog grows without end; without a queue that overflow is what 130429 rejects. Slide arrivals under 80 to watch it settle.

Utilisation is at or above 1: the backlog grows without bound.

01What is error 130429?

Error 130429 (Rate Limit Hit) is the WhatsApp Cloud API error returned when a business phone number sends faster than its throughput, the number of messages per second Meta lets that number push into the platform. Meta's description is simply that Cloud API message throughput has been reached. The send request is refused, no WAMID is created, and the message has to be sent again later or it never reaches the customer. Of all the API error codes, it is the one that grows with your volume rather than with your bugs.

Throughput (MPS) is set per registered phone number. By default it is up to 80 messages per second. Meta upgrades a number automatically and free of charge to 1,000 messages per second when its business portfolio has an unlimited messaging limit, has messaged 100,000 or more unique users outside a customer service window in a moving 24 hours, and the number's quality rating is medium (yellow) or better; while the upgrade completes, which takes up to a minute, sends can fail with error 131057. Coexistence numbers, shared with the WhatsApp Business app, are fixed at 20 messages per second counting incoming and outgoing traffic together.

130429 is about total speed, not about one customer or about how many people you may reach. Error 131056, the pair rate limit, fires when one business number messages the same recipient too quickly. Messaging limits cap how many unique users a portfolio may contact outside a service window in a rolling 24 hours. Graph API call limits, such as error 4 or 80007, count API calls rather than messages. A send queue that paces each number below its throughput is the standard cure, and good rate limiting design keeps real-time traffic ahead of bulk sends.

Key takeaways

  • Error 130429 means a phone number exceeded its Cloud API throughput, the number of messages per second it may send.
  • Default throughput is up to 80 messages per second per number; eligible numbers are upgraded automatically, free, to 1,000.
  • Rejected sends never became messages, so they aren't billed, but they are lost unless your code sends them again.
  • Prevent it with one paced send queue per phone number, and retry with jittered backoff when it still appears.
  • It differs from 131056, the pair rate limit, which caps how fast you message one recipient.

02Why does error 130429 matter?

Bulk sends are where 130429 appears: a broadcast job that fires 5,000 requests in a tight loop, or several workers each sending at full speed from the same number. Each rejected request is a message that quietly didn't go unless your code resends it, and the classic symptom is a campaign report showing 4,200 sent out of 5,000 with no failed statuses, because the missing 800 never got a WAMID. Pacing per number keeps every message accounted for and makes campaign finish times predictable.

03 · How it works, step by step

How does error 130429 work?

  1. Step 1

    Know each number's throughput

    Assume up to 80 messages per second unless Meta has notified you of an upgrade to 1,000; coexistence numbers get 20. The limit belongs to the phone number, not to your app or your server.

  2. Step 2

    Put a queue in front of the API

    Producers add sends to a queue; one paced consumer per phone number takes jobs at a fixed rate, for example with the token bucket algorithm refilling at 70 tokens per second for an 80 mps number.

  3. Step 3

    Budget all traffic from the number

    Service replies, OTPs and campaign messages share the same throughput. Give real-time traffic its own priority lane so a broadcast never delays a one-time password.

  4. Step 4

    Back off when 130429 still appears

    Re-queue the rejected message and retry with exponential backoff plus jitter rather than immediately, and lower the consumer's rate for a while if the errors repeat.

  5. Step 5

    Monitor rejections

    Count 130429 per number per minute. A steady trickle means pacing is too aggressive; a sudden burst usually means a new producer is bypassing the queue.

04Error 130429 in code

// One paced consumer per business phone number, below its throughput.
const RATE = 70;                                   // msgs/s, headroom under 80 mps
const sleep = (ms) => new Promise((r) => setTimeout(r, ms));
 
async function drain(queue, send) {
  let tokens = RATE, last = Date.now();
  while (queue.length) {
    const now = Date.now();
    tokens = Math.min(RATE, tokens + ((now - last) / 1000) * RATE);
    last = now;
    if (tokens < 1) { await sleep(10); continue; }
    tokens -= 1;
    const job = queue.shift();
    send(job).catch((err) => {
      if (err.code !== 130429) return handleOtherError(job, err);
      job.attempt = (job.attempt ?? 0) + 1;         // re-queue with jittered backoff
      const delay = Math.random() * Math.min(60000, 1000 * 2 ** job.attempt);
      setTimeout(() => queue.push(job), delay);
    });
  }
}

Simplified: in production the queue is durable (Redis, SQS, a database) and the consumer keeps running.

05Error 130429: key facts and limits

Default throughput
Up to 80 messages per second per number
Upgraded throughput
1,000 mps, automatic and free when eligible
Coexistence numbers
20 mps, incoming and outgoing combined
During an upgrade
Up to 1 minute; error 131057 meanwhile
Billing
Rejected sends are not charged
Not to confuse with
131056 pair rate limit (one recipient)

06Example: A Diwali broadcast from Jaipur

A Jaipur jewellery brand, on a portfolio with a 100,000 messaging limit, schedules a Diwali offer to 60,000 opted-in customers from one number at the default throughput. The first version ran 20 parallel workers with no shared pacing, logged about 9,000 130429 errors in the first minute and dropped those messages. The fix was one queue for the number with a token bucket at 70 messages per second and a priority lane for OTPs and agent replies. The same 60,000 sends now finish in just over 14 minutes with no rate-limit errors, and support replies leave within seconds throughout.

07 · Common mistakes, and the fix

Common mistakes with error 130429

  • Firing a broadcast in a tight loop

    Thousands of concurrent requests from one number hit the limit within a second. Send through a queue that releases messages at a steady rate.

  • Pacing per worker instead of per number

    Throughput belongs to the phone number. Ten workers each pacing themselves at 80 per second still push 800 per second through the same number; share one limiter per number.

  • Retrying immediately

    An instant retry lands in the same overloaded second and fails again, multiplying the load. Back off exponentially with jitter, and slow the producer.

  • Keying retries on HTTP 429 alone

    Don't assume the HTTP status will be 429. Read error.code in the JSON body and treat 130429 as retryable-after-delay.

  • Leaving rejected sends out of reports

    A rejected send has no WAMID and no status webhook, so it vanishes from delivery dashboards. Record it as its own outcome until it is resent.

08 · Tips from the bench

Best practices for error 130429

  • Leave 10–15% headroom under the limit for replies and authentication messages.
  • Run separate priority lanes: OTPs and agent replies first, marketing last.
  • Spread big campaigns over time rather than over more workers.
  • If you send from several numbers, pace each one independently; throughput is per number.

09Error 130429 (Rate Limit Hit) FAQs

What is the WhatsApp Cloud API rate limit per second?+
Up to 80 messages per second per business phone number by default. Numbers that meet Meta's criteria are upgraded automatically to 1,000 messages per second, and coexistence numbers are fixed at 20.
Are messages that fail with error 130429 charged?+
No. The request was rejected before a message existed, and Meta bills delivered messages only. You do have to resend them, or they never reach the customer.
How do I fix WhatsApp error 130429?+
Pace sends per phone number below its throughput with a queue, and retry rejected messages after an exponential, jittered delay. Adding workers makes it worse, not better.
What is the difference between error 130429 and 131056?+
130429 is the number's total speed limit across all recipients. 131056 is the pair rate limit for sending too many messages to the same user too quickly, so it needs per-recipient spacing instead.
Does a higher messaging limit raise throughput?+
Not directly. Messaging limits cap unique users per rolling 24 hours, while throughput caps messages per second; an unlimited messaging limit is one of the conditions for the 1,000 mps upgrade.

See InfiQ pricing

From definition to your first message

InfiQ is an official Meta Business Partner. Start a 7-day free trial — no card needed — and see this running on your own number.

Start free trialBrowse all 550 terms