Error 130429 is documented as "Rate Limit Hit: Cloud API message throughput has been reached." (ChakraHQ, retrieved 2026-08-24; Dualhook, retrieved 2026-08-24). ChakraHQ gives the HTTP status as 400. Meta's public error-code reference could not be retrieved when this article was last checked, so the wording above is quoted from BSP documentation rather than from Meta. Confirm the current text against Meta's own reference before you build error handling on it.
What most guides get wrong: they publish a "250 / 500 / 1,000 messages-per-second tier ladder" that appears in no source we could verify. The only documented path is 80 to 1,000, with two named conditions.
It belongs to our reference on WhatsApp Business API error codes.
What error 130429 means
Error 130429 is a throttle on send rate. The Cloud API accepted your request, your token and your template, then rejected the message because the phone number was pushing messages faster than its messages-per-second ceiling. Nothing is wrong with the payload. The same request sent a second later usually succeeds.
That makes it behave differently from a validation or authentication failure, which returns the same result forever. Dualhook classifies 130429 as retryable, alongside codes 4 and 80007 (Dualhook, retrieved 2026-08-24). Retryable does not mean "retry instantly". It means the request can succeed later if you slow down.
The default: 80 messages per second per number
The documented default is 80 MPS per phone number. AWS End User Messaging Social states it plainly: "By default, each phone number has an MPS of 80" Heltar gives the same figure independently
Two details matter more than the number itself. First, the limit is per phone number, not per WhatsApp Business Account and not per app. Each sending number gets its own ceiling, which is why teams add numbers as volume grows. Weigh the trade-offs of running multiple numbers on one WhatsApp Business Account first.
Second, the unit is per second. Eighty per second is a large daily figure if traffic is even and a very small one if it all arrives at 09:00. Most teams that hit 130429 are not over their daily volume. They are over their peak-second volume.
The upgrade path Meta documents, and the tier ladder nobody can source
One increase is documented: 80 MPS to 1,000 MPS. AWS states that "Meta can increase your MPS to 1,000 if you meet the following requirements" and names two (AWS End User Messaging Social, retrieved 2026-08-24):
- "The phone number must be able to send an unlimited number of business-initiated conversations."
- "The phone number must have a quality rating of medium or higher."
Heltar also cites 1,000 MPS as the raised figure.
The intermediate steps that circulate widely, usually written as 250 then 500 then 1,000, appear in no source we could verify. They may exist inside Meta's systems, but no reachable documentation publishes them, so do not plan capacity around them. Plan against 80 and treat 1,000 as the documented target.
A second repeated claim also failed verification: that an upgrade causes brief downtime or a maintenance window. No source we could reach supports it, and the AWS page states eligibility conditions and nothing about downtime. We are not asserting the opposite either. Ask your BSP what happens on your account before scheduling an upgrade near a campaign.
Throughput vs API call limits vs messaging tiers
These limits are separate systems, and confusing them sends teams chasing the wrong fix.
Limit | Error code | What it caps | Scope | Typical cause |
|---|---|---|---|---|
Message throughput | 130429 | Messages per second | Per phone number | Burst sending, uncoordinated workers |
API call rate limit | 4 | All Graph API calls per hour | Per app, per WABA | Polling endpoints, template and status fetches |
WABA-level limit | 80007 | Account-level request volume | Per WhatsApp Business Account | Aggregate load across the account |
Messaging tier | n/a | Unique users you can message in 24 hours | Per phone number | Reaching the daily unique-recipient cap |
The confusion that costs most time is 130429 versus error 4, documented as "API Too Many Calls: The app has reached its API call rate limit" (Dualhook, retrieved 2026-08-24). Error 4 counts every Graph API call, including template lookups and status polls, so you can trigger it while sending almost no messages. Error 130429 is only ever about send rate.
Messaging tiers cap how many unique users you can message in a rolling 24 hours, not how fast you send. We did not verify the current tier numbers in this run, so we are not publishing them. Sibling articles cover error 4 and error 80007.
What to do when you hit it: queue, pace, retry safely
Slow the sender down, then drain a queue. Do not loop on the same request.
- Branch on the numeric code, not the message text. BSP guides advise building logic on
130429itself, because titles vary between tables. - Return the message to a queue rather than retrying inline. Inline retries from many workers deepen the burst.
- Apply exponential backoff with jitter, so parallel workers do not resynchronise into a new spike.
- Throttle at the source. A token-bucket limiter shared by every worker on that number is the only reliable control; per-process limits fail once you scale out.
- Keep the
fbtrace_id. Dualhook recommends retaining it for support escalation.
The pacing patterns in our guides on sending bulk WhatsApp messages and high-volume campaign delivery are the same ones that keep you under 130429.
Qualifying for higher throughput
Both documented conditions concern account health, not volume history.
Quality rating of medium or higher. Quality rating reflects how recipients respond: blocks and reports pull it down. Marketing to unengaged lists is the fastest way to lose eligibility. Our notes on WhatsApp template pacing versus pausing explain how Meta reacts to quality problems before it blocks a template.
Unlimited business-initiated conversations. This is a state the number has to be in, tracking business verification and messaging limit status. If the number is still capped, throughput is not the limit to work on.
Neither condition can be rushed. If delivery problems already sit alongside the throttling, our guide to WhatsApp messages not being delivered covers the adjacent causes.
Designing a sender that stays under the limit
Build the limit into the sender rather than discovering it through errors.
- Rate-limit centrally. One limiter per phone number, shared by all workers, set below the ceiling so headroom absorbs retries.
- Split campaign and transactional traffic. Order confirmations and OTPs should not queue behind a marketing blast.
- Smooth the burst. A large list does not need to be reached in one second. Spread the send across minutes.
- Alert on the rejection ratio, not the raw count of 130429 responses.
- Do not poll for status. Subscribe to webhooks. Polling drives error 4 without helping throughput, and the wider picture of WhatsApp API rate limits shows how the two interact.
A minimal Cloud API send, for reference, is:
curl -X POST "https://graph.facebook.com/v<VERSION>/<PHONE_NUMBER_ID>/messages" \
-H "Authorization: Bearer <TOKEN>" \
-H "Content-Type: application/json" \
-d '{
"messaging_product": "whatsapp",
"to": "<RECIPIENT>",
"type": "template",
"template": {
"name": "<TEMPLATE_NAME>",
"language": { "code": "<LOCALE>" }
}
}'The request that returns 130429 is identical to the one that succeeds. Only the timing differs, which is why architecture, not payload debugging, is the fix. Teams reviewing a setup end to end may find our WhatsApp API integration and bulk message sender notes useful.
Frequently Asked Questions
What is the default WhatsApp Cloud API message throughput?
The documented default is 80 messages per second per phone number. AWS End User Messaging Social states that "By default, each phone number has an MPS of 80", and Heltar gives the same figure independently. The limit applies per phone number rather than per WhatsApp Business Account, so each sending number has its own ceiling. Confirm it against Meta's own reference before sizing infrastructure.
How do I get my message throughput increased?
AWS documents one increase: 80 MPS to 1,000 MPS. It states that "Meta can increase your MPS to 1,000 if you meet the following requirements": the number must be able to send an unlimited number of business-initiated conversations, and it must have a quality rating of medium or higher. Both are account-health conditions, not volume commitments. Your provider raises the request once the number qualifies. No other tier is documented.
Is there downtime during a throughput upgrade?
This is unverified. The repeated claim that a throughput upgrade causes a short outage or maintenance window is not supported by any source we could reach in this run. The AWS page documenting the upgrade states eligibility conditions and says nothing about downtime. We are not asserting that downtime does or does not occur. Ask your provider before scheduling one.
Is 130429 the same as being rate limited by error 4?
No. Error 130429 caps messages per second from one phone number. Error 4 is documented as "API Too Many Calls: The app has reached its API call rate limit" and counts every Graph API call, including template lookups and status polls. An app that polls heavily can trigger error 4 while sending very few messages. The two have separate causes and separate fixes.
Should I retry a message that returns 130429?
Yes, but not immediately and not inline. Dualhook classifies 130429 as retryable, unlike authentication failures, which can never succeed on retry. Return the message to a queue, apply exponential backoff with jitter, and lower the shared send rate before draining it. Retrying instantly from several workers deepens the burst that caused the rejection and produces more failures.
Getting throughput planning right before it becomes an incident
Throughput limits are predictable, which makes them a design problem rather than a support problem. If you are planning a high-volume WhatsApp programme and want sending architecture, pacing and account health reviewed together, talk to an expert.
