WhatsApp error 131056: 1 message every 6 seconds

What does WhatsApp error 131056 mean, and what is the actual limit?

Error 131056 means you sent messages too quickly from one business phone number to one recipient's phone number. Meta does publish the exact rate — 1 message every 6 seconds to the same WhatsApp user — it simply does not publish it on the error-codes page you almost certainly landed on.

The error-codes entry files 131056 under "Throttling errors" and describes it as:

"Too many messages sent from the sender phone number to the same recipient phone number in a short period of time." (Meta — WhatsApp Cloud API error codes)

with a remedy that names no figure at all:

"Wait and retry the operation, if you intend to send messages to the same phone number. You can still send messages to a different phone number without waiting." (Meta — WhatsApp Cloud API error codes)

That is the whole entry. Wait, and retry. Every vendor helpdesk page about this code paraphrases those two sentences, adds "slow down" or "bundle your messages into one", and stops — because the page they are reading genuinely contains no number. The number is on a different page, under a heading most people never reach, and it changes what you should build.

• What does WhatsApp error 131056 mean, and what is the actual limit?
• Where does Meta publish the pair rate limit figure?
• Why does a 131056 arrive minutes after the burst that caused it?
• What backoff does Meta prescribe after a pair rate limit?
• Does the pair rate limit cost you any account throughput?
• Which sending patterns actually trigger a pair rate limit?
• Which throttling error is which: 131056, 130429 or 131049?
• Why is the old rate-limits URL the wrong page to follow?
• What is 131057, and why does it look like a rate limit?
• How should a send queue be built so 131056 never fires?

Where does Meta publish the pair rate limit figure?

Under the heading "Pair rate limits" on About the WhatsApp Business Platform, not on the error-codes reference and not on the throughput page. The sentence is specific:

"Business phone numbers can send 1 message every 6 seconds to the same WhatsApp user (0.17 messages/second), which equals about 10 messages per minute or 600 per hour." (Meta — About the WhatsApp Business Platform)

and the same section names the code outright:

"Exceeding this limit triggers error code 131056 until you are back within the allowed rate." (Meta — About the WhatsApp Business Platform)

The throughput page gestures at the same rule without giving the figure: "If you attempt to send too many messages to the same WhatsApp user number, you may encounter a pair rate limit error." (Meta — Throughput)

So three Meta pages describe this limit and only one of them quantifies it. If you have read that 131056 is undocumented, or that Meta declines to say how fast is too fast, that is a claim about the error-codes page rather than about Meta's documentation. Checked against Meta's documentation on 11 September 2026.

Code:        131056
Section:     Throttling errors
Description: Too many messages sent from the sender phone number to the
             same recipient phone number in a short period of time.
Published
rate:        1 message / 6 seconds / recipient  (0.17 mps, ~600 per hour)

Why does a 131056 arrive minutes after the burst that caused it?

Because the limit is a budget you can overdraw, not a gate that closes. Meta's own wording:

"You may send up to 45 messages in a 6-second burst, but this "borrows" from your future quota. After a burst, you must wait the equivalent time it would take to send those messages at the normal rate (for example, a burst of 20 requires a ~2-minute wait before sending more to that user)." (Meta — About the WhatsApp Business Platform)

Read that twice, because it inverts the obvious mental model. A rapid sequence to one customer does not fail. It succeeds, in full, and every message is accepted. The penalty is deferred, and it lands on whatever you send to that same person next — which is usually one ordinary, low-volume, entirely reasonable message some minutes later.

That is why the error reads as random to whoever is on call. The failing request is not the offending request. Nothing in the response points backwards at the burst that spent the quota, so the log line you are staring at describes the victim rather than the cause.

Meta publishes one worked example, the burst of 20. The rest of the column below is that rule applied arithmetically at six seconds a message, not a table Meta publishes.

What backoff does Meta prescribe after a pair rate limit?

A base-four schedule, which is considerably slower than most retry code assumes:

"To manage post-burst throttling, if a send request fails, retry after 4^X seconds (starting with X=0 and increasing X by 1 after each failure) until successful." (Meta — About the WhatsApp Business Platform)

This matters more than it looks. The default retry in most HTTP clients and job queues is exponential doubling from one second, often with a ceiling of thirty or sixty seconds. Against a two-minute debt, a doubling backoff spends its attempts inside the window it is meant to wait out, and each failed attempt is another request Meta refuses.

By the fourth failure Meta's schedule has waited 85 seconds and a doubling one has waited 15. Only the first is anywhere near the ~2 minutes Meta's own burst example describes.

Does the pair rate limit cost you any account throughput?

No, and this is the conflation that turns a harmless figure into a scary one. The 0.17 messages per second is per sender-and-recipient pair. Your number's own capacity is a separate published number, and Meta scopes it explicitly in the same sentence:

"For each registered business phone number, Cloud API supports up to 80 messages per second (mps) by default, and up to 1,000 mps by automatic upgrade." (Meta — Throughput)

Read the opening clause. Throughput is counted per registered business phone number and it counts messages, whoever they go to. The pair limit is counted per sender-and-recipient pair. Two different denominators, which is the whole reason the two figures can look contradictory and are not.

A number running at 80 mps still runs at 80 mps. It simply has to be sending to 80 different people rather than 80 times to one. Meta's own remedy for 131056 says as much: "You can still send messages to a different phone number without waiting."

So "600 messages per hour" is not an account ceiling, and any page that presents it as one has misread the scope. A campaign to ten thousand distinct contacts is untouched by the pair limit, because it touches each pair exactly once. What actually caps that campaign is a different set of limits entirely, covered in what actually caps a WhatsApp broadcast.

Exceed the per-number rate instead and Meta returns a different code: "If you attempt to send more messages than your current throughput level allows, the API will return error code 130429 until you are within your allowed level again." (Meta — Throughput)

Which sending patterns actually trigger a pair rate limit?

Here is the contrarian half. For most businesses hitting 131056, it is not a marketing-blast problem at all. Broadcasts fan out across many recipients, which is exactly the shape the pair limit ignores. What concentrates messages onto one pair is your own reply logic, and every one of these is under your control:

• The multi-bubble greeting. A bot that answers with a welcome, then a menu, then an image sends three messages in perhaps a second. Nothing fails — it is well inside the 45-message burst — but it has just borrowed about eighteen seconds of quota from that pair. Do it again on the customer's next two replies and the bucket never refills.
• A retry loop with no per-pair key. A job that retries a failed send against the same recipient, on a queue that also holds the original, spends quota twice for one message.
• Echo-triggered auto-replies. If an outbound echo re-enters the same handler that generates replies, each reply produces the next. The loop is bounded by the pair limit rather than by your code, so 131056 is the first symptom of a bug that has nothing to do with rate limiting.
• Two systems on one number. An automation and a human agent answering the same thread at once are one pair, however separate they look on your side.

The practical tell is timing. Open the per-message log, filter to a single recipient, and read the timestamps rather than the failure. If several sends sit inside the same second some minutes before the 131056, you have found the burst.

A dashboard that only shows a conversation view will not answer this, because bubbles rendered in a thread hide how close together they were sent. A log with a real timestamp column will.

Which throttling error is which: 131056, 130429 or 131049?

131056 and 130429 both sit under Meta's "Throttling errors" heading. 131049 does not — Meta files it under "Other errors" — and it still reads exactly like the same complaint. All three feel like "you are sending too much". They are three unrelated mechanisms, and only one of them responds to slowing down.

131049 is the one people mistake for a pair limit, because it also fires per recipient. It is not yours to pace. Meta describes the underlying rule as: "WhatsApp may limit the number of marketing template messages a WhatsApp user receives from any business in a given period of time when they are less likely to be receptive and engage with those messages." (Meta — Per-user marketing template message limits)

Two clauses there do the damage: any business, and engage. The budget is summed across every business messaging that person, and the same page adds that "the per-user marketing limit adapts automatically over time based on a person's recent engagement levels." No figure is published, and slowing your own sending cannot restore someone else's engagement. The full treatment is in what WhatsApp error 131049 means.

131056 is the opposite case, and that is the good news: it is the one throttling error in this family that is entirely a property of your own code.

Why is the old rate-limits URL the wrong page to follow?

Because it now lands on a different concept with a similar name. Meta's WhatsApp documentation has moved from developers.facebook.com/docs/whatsapp/... to developers.facebook.com/documentation/business-messaging/whatsapp/.... The old rate-limits path, /docs/whatsapp/api/rate-limits/, still resolves — through two redirects — onto a page titled Messaging Limits, which opens:

"Messaging limits are the maximum number of unique WhatsApp user phone numbers your business can deliver messages to, outside of a customer service window, within a moving 24-hour period." (Meta — Messaging limits)

That is the 250 / 2,000 / 10,000 / 100,000 / Unlimited tier system. It counts distinct people per day. The pair rate limit counts messages to one person per six seconds. They share no mechanism, no error code and no remedy.

Following a stale link and reading the right heading over the wrong page is a real failure mode here, and it produces a very confident wrong answer: someone concludes their 131056 is a messaging-limit problem, requests a tier review, and waits. Three separate limits, three separate pages:

What is 131057, and why does it look like a rate limit?

It sits one digit away from 131056 in the code numbering — though Meta files it under "Other errors" rather than "Throttling errors" — and it is not a rate limit at all. Meta's error-codes page describes 131057 as the business account being in maintenance mode, and gives a reason that is easy to misread as throttling: "One reason for this could be that the account is undergoing a throughput upgrade." (Meta — WhatsApp Cloud API error codes)

So a number that is in the middle of being made faster refuses sends for a while. Pattern-matching on "13105x" and pacing your sender will not help, and neither will a 4^X backoff aimed at a pair that was never throttled. If sends are failing account-wide rather than to one recipient, this is a state to wait out, and it belongs with the other cases where an account looks healthy and nothing is arriving — see the dashboard says connected and nothing is sending.

How should a send queue be built so 131056 never fires?

The rule is short enough to state in five lines, and it follows directly from the quotations above rather than from anyone's guesswork.

1. Key the rate limiter on the pair, not on the account. One bucket per (business number, recipient number). An account-wide limiter set to 0.17 mps would be catastrophically wrong — it would cap your whole number at ten messages a minute.
2. Space messages to one recipient six seconds apart by default. If a reply genuinely needs several bubbles, send them and then hold that pair for six seconds per bubble before anything else goes to it.
3. Treat the 45-message burst as a debt ceiling, not a licence. It exists so a legitimate multi-part reply is not refused mid-sequence. Spending it in full commits that pair to roughly four and a half minutes of silence.
4. Retry on 4^X seconds, per Meta's text, and only against the pair that failed. Everything queued for other recipients keeps flowing.
5. Log the send timestamp per message, not per conversation. Without it you cannot reconstruct the burst, and the 131056 stays mysterious for as long as you are only looking at the failure.

WabaCRM applies per-number pacing in its own queue for this reason, and keeps a per-message log with a timestamp and failure reason on every row, which is what makes the reconstruction in the section above possible at all. Any platform can do this; the point is that it has to be done per pair, and a conversation-level view will not show you whether it was.

One clarification for numbers running in both the WhatsApp Business app and the Cloud API: Meta documents those as having "a fixed throughput of 20 mps" (Meta — Throughput), which is a 130429 concern and says nothing about the pair limit. The six-second spacing applies just the same — see how coexistence works and what it changes for what else that mode does and does not alter.

Every Meta quotation on this page was read from Meta's own documentation on 11 September 2026. Meta changes that documentation without notice; the linked pages are authoritative and this one is not.