Error 130429: Rate Limit Hit

Error 130429 means a business tried to send faster than its WhatsApp number's throughput allows, and Meta rejected the excess calls until the rate comes down. VGraple CRM's own sending is deliberately paced under this ceiling by default, so most organisations never see this error; it mainly shows up on direct API integrations sending at their own speed.

Symptom

A send attempt, usually a burst of many in quick succession, fails with error 130429, with Meta's title reading close to "Rate limit hit." The response typically indicates the call exceeded the number's throughput limit or a related Meta-side rate limit, such as sending too many messages to the same recipient within a short window (a separate, related code, 131056, covers that specific case in more detail). Inside VGraple CRM's own broadcast, sequence and flow sending, 130429 is rare because every send is already paced below the throughput ceiling before it reaches Meta; when it is seen, it is almost always from a direct REST API integration or a custom script calling the send endpoint faster than the account's throughput supports.

Why it happens

WhatsApp's Cloud API enforces a per-number throughput ceiling, roughly 80 messages a second for combined sending and receiving on a standard Cloud API number, and a lower ceiling, around 20 messages a second, for a coexistence number (one shared with the WhatsApp Business app on a phone). This exists to protect Meta's own infrastructure and to stop a business from flooding the API in a way that would look identical to abuse. A sender that fires requests as fast as its own code can generate them, rather than pacing them against this ceiling, will eventually exceed it, especially during a burst (a large broadcast start, a bulk import triggering welcome messages, or a retry loop resending failed messages without backoff).

The related pair rate limit works similarly but per-recipient: sending many messages to the exact same person in a tight window trips a separate limit meant to catch loops (two automations replying to each other, a broken webhook echoing a message back) rather than genuine high-volume sending across many different recipients.

Fix

1. If this is a direct API integration, add pacing to your own send loop. Space calls so the effective rate stays comfortably under 80 messages a second per number (or 20/s for a coexistence number), rather than firing as fast as your code allows.
2. Back off with increasing delay on a 130429, do not retry immediately. An immediate retry after a throughput rejection is likely to hit the same ceiling again, since the underlying rate has not changed.
3. If the 130429 came from a burst at the very start of a large send (many messages queued to fire in the same second), spread the initial dispatch out rather than triggering them all simultaneously.
4. Check whether the real cause is a loop, not genuine volume. If the same recipient is involved in most of the rejected sends, this points toward the pair rate limit rather than the account-wide throughput ceiling; see errors 131048 and 131056: spam rate and pair rate limits for that specific case.
5. If sending through VGraple CRM's broadcast, sequence or flow screens, this should not recur. The pacer already sends below the number's throughput and halves its rate automatically the moment Meta returns 130429 on any send, so seeing it repeatedly from the product's own screens is unusual and worth checking channel health for.

How VGraple CRM handles it automatically

Every broadcast, sequence step and flow send passes through a token-bucket pacer before reaching Meta, set to 50 messages a second by default per number, comfortably under Meta's roughly 80/s ceiling, so a short burst of retries or a fast-starting campaign never trips the hard limit in normal operation. If Meta does return 130429 mid-campaign despite this, the pacer halves its rate immediately for that number and does not recover automatically; the remainder of the campaign finishes slower on purpose, since recovering the rate straight back up would risk tripping the same limit again on the very next batch. A coexistence number is paced at a flat 4 messages a second regardless of quality rating, well under Meta's own roughly 20/s ceiling for that connection type, since a coexistence number's throughput headroom is inherently narrower.

Prevention

The most effective prevention for anyone using VGraple CRM's own sending screens is simply to keep using them rather than building a parallel direct API sender for large volumes, since the pacing, backoff and quality-aware rate adjustment are already built in and require no configuration. For a direct API integration, prevention means implementing your own pacing and exponential backoff rather than treating 130429 as an occasional error to log and ignore; a naive retry loop, especially one retrying immediately with no delay, is the single most common way an integration turns an occasional throughput bump into a sustained problem. See pacing, daily limit budget and auto-resume for how the product's own rate adapts to quality rating on top of the base throughput ceiling.

Does 130429 mean my number is in trouble?

Usually not. A single 130429 during a burst is an ordinary, expected part of sending at volume and, on its own, says nothing about your number's standing with Meta; it is a technical speed limit, not a quality or policy signal. What matters is the response to it: a sender that backs off and paces itself afterward, as VGraple CRM's own pacer does automatically, treats 130429 as the routine throughput protection it is. A sender that ignores it and keeps retrying at the same speed risks two compounding problems: since April 2026, Meta counts excessive failed retries against the account, and repeated throughput violations are one of several signals that can draw attention during a quality review, even though 130429 itself is not a quality-rating event. If 130429 recurs constantly rather than occasionally during genuine bursts, that pattern, not any single occurrence, is the thing worth investigating.