Errors 131048 and 131056: Spam Rate and Pair Rate Limits

Error 131048 means Meta has restricted your number outright for a spam-rate breach; error 131056 means you sent too many messages to one specific person in too short a time. They come from different causes, account-wide sending behaviour for 131048, a single loop or flood for 131056, and each needs a different fix.

Symptom

Error 131048, titled close to "Spam rate limit hit," appears on sends from a number Meta has temporarily restricted, and typically every send from that number fails, not just some. The channel card in Settings then Channels then WhatsApp shows a restricted status alongside the expected recovery window if Meta has communicated one. Error 131056, "Business account and consumer account pair rate limit hit," appears only on sends to one specific recipient who has received too many messages from your number in a short period; other recipients continue receiving messages normally, which is the clearest way to tell the two apart at a glance.

Why it happens

131048 is Meta's enforcement step after a phone number's quality rating has already been showing signs of trouble, usually a run of blocks and spam reports that crossed a threshold Meta does not publish. It is a step beyond a plain YELLOW or RED quality rating: rather than only slowing the number down, Meta stops it from sending at all for a period. The underlying cause is almost always sending unwanted marketing content at volume to an audience that reacts badly, cold lists, purchased numbers, or broad "everyone" blasts, the same behaviour that drives a quality rating down in the first place.

131056 has a completely different root cause: it is a technical loop guard, not a content or audience quality issue. A real human conversation, even a very active one, essentially never sends enough messages to one person in a short enough window to trip it. It almost always comes from an automation misfire: two chatbot flows or automation rules replying to each other in a cycle, a webhook that echoes an inbound message back out, or a sequence with a broken condition that keeps firing the same step repeatedly.

Fix

For error 131048:

1. Stop sending marketing to broad or unengaged lists immediately. Continuing to send at the same pace and to the same kind of audience is what turns a temporary restriction into a longer or recurring one.
2. Check the channel card for the restriction's expected end, if Meta has communicated one; there is no manual review or appeal button, recovery is behavioural and time-based.
3. Review what was sending when the restriction hit. A specific campaign, template, or list is usually the identifiable trigger; understanding which one prevents repeating the same mistake once sending resumes.
4. Once sending is possible again, start with your most engaged, recently active contacts only, not a full resumption of the list that caused the restriction. See phone number quality rating for the same recovery principle applied to a quality-rating drop.

For error 131056:

1. Check the message log for the affected recipient and count how many messages went out in a short window. A number well beyond normal conversation volume, dozens in minutes, points directly at an automation loop.
2. Review flows and automation rules for a cycle. Two flows or rules that can trigger each other (one replies to a keyword that is itself the other's trigger keyword) is the single most common cause.
3. Check for a webhook echoing messages back. An outbound webhook receiving a message event and, through a misconfigured downstream system, sending it back into the same conversation creates exactly this loop.
4. Add or tighten a loop guard on the responsible automation once identified, rather than only fixing the immediate recipient; the same misconfiguration will trip again on the next person it reaches.

How VGraple CRM handles it automatically

On a 131048 restriction, every broadcast currently sending from the affected number halts, with every recipient's state preserved exactly as it was rather than marked failed or lost, and the channel shows the restriction alongside its expected end where Meta provides one. The org owner is alerted immediately so the cause is discovered from VGraple CRM, not from a wave of customer complaints or a support ticket days later. On 131056, flows and automation rules carry built-in loop guards and per-contact rate limits specifically designed to stop a runaway condition before it reaches Meta's own limit; if 131056 does still appear despite these guards, the message log for that conversation shows the full sequence of sends leading up to it, which is normally enough to identify the responsible automation immediately rather than guessing.

Prevention

For 131048, the same list hygiene and audience discipline that protects quality rating protects against spam-rate restriction directly, since they draw on the same underlying signals: prioritise recently engaged contacts, avoid purchased or scraped lists, and space marketing sends to the same list by more than a day. For 131056, review any new flow or automation rule for the possibility that its trigger condition could also match its own output or another automation's output before publishing it live; a brief manual test, sending yourself a message that could plausibly trigger a loop, catches most of these before real customers ever encounter them.

How do I know which one I am dealing with?

Scope is the fastest signal: if every send from a number is failing regardless of recipient, that is 131048, an account-wide restriction. If sends are failing or being rate-limited to one specific recipient while everyone else on the same number receives messages normally, that is 131056, a per-recipient pair limit almost certainly caused by a loop rather than genuine volume. The two are frequently confused because both ultimately stem from Meta protecting recipients from unwanted volume, but the fix could not be more different: 131048 needs a change in audience and frequency across the business, while 131056 needs a specific automation found and fixed.