One recipient stops receiving your WhatsApp messages while every other conversation keeps working. The dashboard shows no policy violation, no quality drop, no account restriction — just a 400 error with code 131056. Most teams assume their whole WhatsApp Business Account got throttled and start slowing down everything they send. That reaction is usually wrong, and it costs them message volume they did not need to lose.
What Error 131056 Actually Is
Meta’s own Cloud API documentation defines 131056 as a “(Business Account, Consumer Account) pair rate limit hit.” The trigger is too many messages sent from one business phone number to the same recipient phone number in a short window. It is scoped to that one sender–recipient pair — not to the WhatsApp Business Account, not to the phone number as a whole, and not to your app’s general throughput.
What Triggers It
Repeated sends to the same consumer number in a short period — retries, duplicate webhooks firing twice, or a broken de-duplication check in an automation flow.
What It Does NOT Mean
It is not a quality-rating drop, not a spam flag, and not a WABA-wide throughput ceiling. Meta’s documentation is explicit that other recipients are unaffected.
131056 vs the Other WhatsApp Throttling Codes
Cloud API returns several different 4xx codes under the umbrella of “rate limit,” and they are not interchangeable. Confusing one for another leads teams to fix the wrong layer of their sending logic.
| Code | Scope | What It Signals |
|---|---|---|
| 131056 | Single sender–recipient pair | Too many messages to one specific consumer number |
| 130429 | App-wide throughput | Cloud API message throughput ceiling reached |
| 131048 | Account-wide | Spam rate limit from blocked or flagged messages |
| 133016 | Phone number | Register/deregister attempts exceeded — see our 133xxx registration error guide |
The practical distinction: Meta’s own error description for 131056 states you can keep sending to a different phone number without waiting. Pausing your entire send queue over a single-pair error usually throttles traffic that was never at risk.
How This Plays Out in Practice
A workflow retries silently
An automation platform, chatbot builder, or CRM integration resends the same message to the same customer after a slow or missing delivery confirmation.
A webhook fires more than once
Duplicate inbound events trigger duplicate outbound replies to the same number before a de-duplication check catches them.
Support and marketing tools overlap
Two separate systems both messaging the same customer independently can combine to trip a pair-level limit neither system sees on its own.
The account-wide reaction makes it worse
Teams that respond by throttling their whole send pipeline lose delivery speed to every other unaffected recipient for no reason.
Where This Gets Missed
Public error-code round-ups mostly repeat Meta’s one-line description without explaining why the limit is pair-scoped or what actually causes repeat hits at that specific level. For a SaaS platform or agency sending on behalf of many end-users, the real risk is architectural: multiple integrations, retries, and webhook handlers can all target the same customer number without any single system realizing another one already sent recently. Diagnosing that requires tracing message logs across every system touching that WhatsApp number — not just reading the error code in isolation.
Getting This Right on a Production WhatsApp Integration
A one-off automation script can usually absorb a 131056 with a simple retry delay. A SaaS platform, agency, or business sending WhatsApp messages through multiple integrations needs the send pipeline, webhook handling, and de-duplication logic built so this error does not cascade into a wider slowdown. I provide WhatsApp Cloud API setup and approval support, including reviewing how a messaging architecture handles throttling and rate-limit codes like this one. For a broader look at how throughput and quality tiers work at the account level, see the WhatsApp Business API quality rating guide.