Error 130429 · HTTP 400
Rate limit hit
A throughput cap that arrives dressed as a client error.
Cause. A throughput cap on the account, not a problem with the message. Meta returns it as 4xx rather than 429.
Fix. Back off and resume. Treating this as a client error permanently fails messages that a rolling window would have released within the hour.
Why the status code misleads
Every HTTP client is taught that 4xx is the caller's fault and must not be retried, while 429 and 5xx are transient. Meta returns this account-level throughput cap as an ordinary 400.
A correct implementation of the standard rule therefore fails these permanently. Nothing in the response says a cap was involved, so the only visible symptom is a send that partly delivered.
What it costs on a broadcast
A cap engages partway through a large send. Messages before it deliver, messages after it are refused, and if those are marked permanent the tail of the broadcast is discarded and never retried. The front half worked, so every dashboard says the integration is fine.
Handling
Back off and resume; the window clears on its own. Distinguish it from 131056, which is scoped to one conversation rather than the whole account: 130429 means slow down everything, 131056 means slow down for one person.
The whole table, free
Every code we document, with the handling decision each one implies, as an open dataset. The flags are generated by running the same classifier our production send path uses, so it cannot describe behaviour the software does not have. CC-BY, CORS open.