Error 368 and Account Restrictions

Error 368 means Meta has restricted the WhatsApp Business Account itself, not just paced or slowed the number, for a specific policy violation it names in a notice. Recovery here is different from most other delivery errors: it usually requires an appeal in Meta Business Manager, not just a change in sending behaviour and a wait.

Symptom

Every send from the affected number fails, with the error naming that the account is "temporarily blocked for policies violations," matching Meta's own title for code 368. Unlike a quality-rating slowdown or a spam-rate restriction, Meta typically also sends a direct notice to the WhatsApp Business Account admin naming the specific policy violated, and this notice is where the appeal window and process are described. VGraple CRM's channel card reflects the restricted status and links directly to the appeal path in Meta Business Manager rather than offering its own resolution, since the decision and any reversal sit entirely with Meta.

Why it happens

368 is triggered by a genuine policy violation Meta has identified, distinct from the throughput and quality-rating mechanisms that drive most other delivery errors. Common causes include sending content Meta classifies as spam at a volume or pattern that crosses its threshold, sending prohibited content (certain regulated categories, misleading claims, content resembling a scam), impersonating another business or individual, or a sustained pattern of user reports that Meta's trust and safety systems have flagged as a policy matter rather than only a quality signal. Where a low quality rating or a 131048 spam-rate restriction can result purely from aggregate recipient reaction over a rolling window, 368 reflects a specific violation Meta's own review has identified and is prepared to name.

Fix

1. Read Meta's notice carefully for the specific policy cited. The notice, sent to the WhatsApp Business Account admin, names the exact policy violated; the fix has to address that specific issue, not a general assumption about what went wrong.
2. Open Account Quality in Meta Business Manager to see the restriction's full scope and the window available to appeal.
3. Gather evidence relevant to the specific violation before appealing. For a consent-related violation, this means documentation of how affected recipients opted in; for a content violation, it means the specific templates or messages Meta flagged and any changes already made to them.
4. Submit the appeal through Business Manager within the stated window, addressing the named violation directly rather than a general request for reinstatement.
5. While the restriction is active, do not attempt to work around it by moving the same content to a new number. A pattern of moving between numbers to avoid a restriction is itself a signal Meta's review process watches for and can extend the underlying problem to the new number too.
6. After the restriction lifts, review whatever caused it before resuming normal volume. Resuming the exact sending behaviour that triggered the violation risks a faster, harsher repeat restriction.

How VGraple CRM handles it automatically

The moment a 368 restriction is detected on a delivery attempt, every broadcast currently sending from the affected number is halted immediately, with every recipient's state preserved exactly as it was, sent, pending, or otherwise, so continued sending cannot deepen the underlying problem and nothing needs to be rebuilt once the restriction is resolved. The org owner is alerted with the restriction named plainly and a direct link into Meta Business Manager's Account Quality section, since the appeal itself has to happen on Meta's own platform and VGraple CRM cannot submit or influence it on the organisation's behalf. The channel card reflects the restricted status clearly rather than showing a generic failure, so the distinction between "this is a policy restriction requiring an appeal" and "this is a rate or quality issue that recovers with better sending behaviour" is visible immediately rather than something the org has to diagnose from a wave of failed sends.

Prevention

The most direct prevention is treating Meta's content and consent policies as binding constraints on template wording and audience sourcing, not guidelines to work around: avoid urgency and scarcity language that reads as manipulative, never use purchased or scraped contact lists, and keep template content honest about what it promises. Since 368 is frequently the escalation point after sustained lower-level signals (a declining quality rating, an earlier 131048 spam-rate restriction) were not addressed, treating those earlier warnings seriously is itself a meaningful prevention for 368; see quality rating dropped to yellow or red and errors 131048 and 131056 for the earlier stages of this same underlying pattern.

Does 368 ever resolve without an appeal?

Meta's notice states the specific restriction period, and in some cases the restriction lifts automatically once that period elapses without requiring a formal appeal, particularly for a first, lower-severity violation. For more serious or repeated violations, an appeal through Account Quality is typically necessary, and the notice itself usually indicates which situation applies. Either way, the safest approach is to read Meta's specific notice rather than assume based on how a previous restriction, or another business's restriction, resolved, since the process and timeline are tied to the specific violation and its severity, not a single fixed rule that applies uniformly to every case.