Error 135000: Business Portfolio Pacing

Error 135000 is Meta's generic catch-all failure code, and in practice it shows up most often while Meta is pacing a business's entire WhatsApp portfolio rather than reacting to anything wrong with a specific send. It is not charged, and blindly retrying it in a loop is the wrong response; the right response depends on whether it is isolated or persistent.

Symptom

A send fails with error 135000, and Meta's title for it is deliberately vague, something close to "Generic user error," with no further detail about the exact underlying cause. If it is isolated to one or a handful of sends, it usually clears on its own within a short time. If it is happening across most or all sends from a WhatsApp number, VGraple CRM will typically have already detected the pattern and shown an organisation-wide alert: "Marketing sending paused by WhatsApp," naming that marketing broadcasts are paused until a specific time, with utility and service messages continuing unaffected.

Why it happens

Meta introduced portfolio-level messaging limits in October 2025, meaning certain restrictions and pacing decisions now apply across a business's entire WhatsApp portfolio, every phone number owned by the same underlying business, rather than being evaluated per number in isolation. A business that is new to the WhatsApp Cloud API, or one that has recently added several numbers, or one whose sending volume has grown quickly relative to its established history, can be paced by Meta at the portfolio level while it demonstrates sustained, healthy sending behaviour. 135000 is the error code that surfaces during this pacing, alongside occasional transient Meta-side faults unrelated to pacing at all, which is why the code carries no more specific description: Meta uses it as a general-purpose rejection rather than a dedicated code just for portfolio pacing.

Fix

1. Check if the failure is isolated or widespread. A single 135000 on an otherwise normal sending day is very likely a transient issue and needs no action beyond a normal retry with backoff.
2. If it is widespread across most sends, check for an organisation-wide marketing halt alert. VGraple CRM surfaces this as soon as the pattern is detected, with the exact time marketing sending is expected to resume.
3. Do not send more, or send faster, to try to push through the pacing. Portfolio pacing exists because Meta wants to see sustained, moderate, well-received sending, not because of a temporary block; pushing harder against it does not resolve it faster and can extend it.
4. Let utility and service messages continue as normal. The pacing is scoped to marketing-category sending; genuinely transactional UTILITY templates and AUTHENTICATION codes are not affected by a portfolio marketing halt.
5. If the portfolio is genuinely new, expect this for a period as normal, not a fault. A newly connected business portfolio, or one that recently added a second or third number, is more likely to see this than an established one with months of steady, low-report sending history.
6. If 135000 persists for days with no resolution and no marketing halt alert showing, it is worth treating as a Meta-side issue rather than pacing; check Meta's own platform status alongside your channel health.

How VGraple CRM handles it automatically

The delivery pipeline treats 135000 as a signal that the business portfolio, not any single number, may be under Meta-side pacing, and responds by halting marketing sending organisation-wide, across every number under that org, for a bounded cooldown period rather than letting every number independently keep retrying into the same restriction. When this halt is armed, the org owner is alerted with the reason and the exact time marketing broadcasts will resume automatically; utility and service messages are explicitly excluded from the halt and continue sending, since portfolio pacing under Meta's own rules targets marketing volume specifically. Running campaigns are not lost, they continue automatically once the halt lifts, so no manual restart or recreation of the campaign is required.

Separately, 135000 failures on individual sends are held and retried on a backoff schedule with a bounded number of attempts rather than retried indefinitely or given up on after a single try, since the code's ambiguity means a persistent failure and a genuinely transient one look identical from a single attempt.

Prevention

There is limited direct prevention for portfolio-level pacing itself, since it reflects Meta's own assessment of a portfolio's maturity and recent sending health rather than a specific configuration mistake. The most effective long-term approach is building sending history steadily: avoid launching a new number straight into high-volume marketing sends, and prioritise low-report, well-targeted campaigns in the first weeks of any new number or newly scaled portfolio, since that is exactly the track record Meta's pacing is designed to reward with fewer restrictions over time. See portfolio-level messaging limits for how the October 2025 change affects daily messaging caps more broadly, and messaging tiers and limits for how a number's tier grows with trustworthy sending history.

Why does Meta not just say "portfolio pacing" instead of a generic error?

Meta's own API documentation is deliberately terse on 135000, treating it as a general-purpose rejection code rather than a dedicated one for this specific situation, which is part of why it is one of the more confusing codes a business can encounter. The practical effect is that no error message alone tells you definitively whether a given 135000 is Meta pacing your portfolio, a transient fault on Meta's infrastructure, or something else entirely; the pattern across your sends, isolated versus widespread, marketing versus utility, recently scaled versus stable, is the only reliable signal available, which is exactly what VGraple CRM's detection watches for rather than reacting to any single 135000 in isolation.