WhatsApp error 131056: (Business Account, Consumer Account) pair rate limit hit

Code 131056 is the pair rate limit: a cap on how fast one business phone number may message one particular WhatsApp user. Meta documents it as 1 message every 6 seconds to the same user (about 10 per minute or 600 per hour). You may burst up to 45 messages to a user within 6 seconds, but the burst borrows from future capacity and you must then wait proportionally before that user can receive more. While the pair is throttled, sends to that one recipient fail with 131056; sends to everyone else are unaffected.

The limit exists to stop a single business from flooding a single person. It is triggered in practice by bots that split one reply into many messages, by retry loops that resend on failure, and by systems that send a status update for every tiny state change.

It is not a quality or spam judgment and it is not the account-wide throughput limit. Waiting clears it.

131056 is returned synchronously with HTTP 400, so the failed message never receives an ID and never generates a statuses webhook - your dispatcher has to catch it at send time. Rule out the two lookalikes before changing code: 130429 throttles the number across all recipients, and 131048 is a quality sanction that waiting does not fix; all three ceilings are tabulated in the WhatsApp limits table. The limit is enforced inside WhatsApp itself, so BSPs inherit it unchanged - API-passthrough providers such as 360dialog surface the Meta code in their error payloads, and per-recipient pacing has to live in your own dispatcher either way.

{
  "error": {
    "message": "(#131056) (Business Account, Consumer Account) pair rate limit hit",
    "type": "OAuthException",
    "code": 131056,
    "error_data": {
      "messaging_product": "whatsapp",
      "details": "Too many messages sent from the sender phone number to the same recipient phone number in a short period of time."
    },
    "fbtrace_id": "Aa1Bb2Cc3Dd4Ee"
  }
}

Rate-limit per recipient as well as per phone number, and collapse rapid-fire notifications into one message per interval. Make sure retries are only triggered for retryable codes and only once per backoff step. A quick test that sends ten messages to a test number in a row will show whether your limiter is working.