WhatsApp Business Platform Policy Violations | Developer Documentation
Review a WhatsApp policy violation notice before requesting review
Use this checklist when Meta identifies a policy violation for the WhatsApp account connected to ChatArchitect. It helps you prepare a factual case for the account owner, support and an available Meta review action. For an active sending restriction, first follow the restriction response guide.
Read the specific notice and current policy
Identify the affected WhatsApp account, the policy or violation label, any referenced content and the current restriction. Follow the policy link supplied with the notice. Use the current WhatsApp Business Messaging Policy, and the commerce policy it links to when the notice concerns a commerce activity.
Meta's violation reference explains labels that may appear. A label alone is not a complete determination of what your business can send: review the actual activity, current rule and any stated conditions. Sector rules and their limited exceptions can change, so an old copied list is not a current approval for your campaign.
Prepare an incident record
| Field | Useful information |
|---|---|
| Notice identity | Date and time with time zone, account and business number, exact label, issue reference and restricted activity. |
| Message or activity | The actual approved template, language, substituted text, link destination, campaign and sending tool involved, if the notice concerns a message. |
| Audience and permission | How that audience was selected, the permission process and any withdrawal or complaint relevant to the issue. |
| Business context | The business represented, the real product or service, and the facts relevant to the particular policy cited. |
| Corrective action and review | What was paused or corrected, by whom and when; any available review action, submission reference and later decision. |
Preserve the notice and the version used at the time. Separate facts you observed from assumptions about the cause. Share only material needed to examine that violation; keep App key, Secret and tokens out of the record sent to support.
Connect the issue with the correct evidence
- Unexpected or unwanted messages: review the permission and withdrawal process, the actual audience selection and sending frequency. Template approval does not prove recipient permission.
- Misleading business identity or offer: compare the business profile, template text, substituted values and destination page with what the business actually provides. Changing a template category alone does not correct a misleading offer.
- Goods, services or commerce activity: compare the actual activity with the current policy cited in the notice, including any stated country, age or activity conditions. Do not infer permission from an old example or from whether a similar message was delivered previously.
- Ownership or rights issue: identify the exact name, image or material disputed and the evidence relevant to its use. Avoid sending unrelated documents or a full customer export.
Prepare a factual review request
If Meta offers a review action, describe the specific decision, the facts you believe were missed, the relevant evidence and any corrective action taken. An illustrative structure is: issue reference; affected account; disputed finding; evidence for that finding; action taken; clarification requested. It is a working outline, not a request already submitted by ChatArchitect.
Use the available review process documented in the Meta enforcement guide. Keep its submission reference and result. A review request does not automatically lift restrictions, and not every spam violation can be appealed. Follow the actual decision before resuming affected sending.
If the account or issue is not visible, check business asset access. Ask ChatArchitect support to help interpret the notice and identify the affected connection; no customer-managed Meta token or webhook subscription is required for this checklist.
No comments to display
No comments to display