Chatwoot App Review Guide: Omnichannel Permissions, Webhooks & Rejection Patterns

A Chatwoot app review is Meta Advanced Access for the Facebook app behind your Chatwoot install — the open-source / self-hosted omnichannel inbox that unifies Messenger, Instagram, and WhatsApp conversations — not Chatwoot’s own license screen, and not a ChatPion-style white-label chatbot SaaS. Meta cares whether a cold reviewer can recreate HTTPS webhook reachability, channel connect, and live inbox proof for each messaging scope you request. This guide diagnoses why Chatwoot App Review fails in the field: messaging-scope honesty, webhook/TLS gaps, unrecreateable inbox demos, and cooldown risk. Diagnosis only — not a DIY secret-sauce checklist or a guaranteed-approval playbook.

What Chatwoot typically needs from Meta

Exact scopes depend on which Meta channels you enable in Chatwoot (Facebook Page / Messenger, Instagram messaging, WhatsApp Cloud API). Field packages commonly include:

• pages_messaging — Page Messenger conversations into the Chatwoot shared inbox (often with honest helpers like pages_show_list / pages_manage_metadata when your connect + webhook subscription path actually uses them)
• instagram_manage_messages — Instagram messaging on the Facebook Login path your Chatwoot channel uses
• whatsapp_business_messaging — WhatsApp Business messaging into Chatwoot when that channel is live
• business_management — only when multi-asset / Business Manager patterns are truly required for your connect flow

Do not paste every Chatwoot integration name into Meta notes. Email, live chat, Telegram, Line, and other non-Meta channels are not fixed by a Meta Chatwoot app review resubmit. Deep Meta permission diagnosis: pages_messaging, instagram_manage_messages, and whatsapp_business_messaging. Sister script guides: ChatPion, BotSailor, Stackposts.

HTTPS webhooks and why Chatwoot app review inbox proof fails

Chatwoot is typically self-hosted. Meta reviewers are not debugging your Docker Compose file — but an unreachable callback still kills recreateability for messaging scopes:

• HTTP or broken TLS — Meta webhook verification and Live delivery expect valid public HTTPS on the callback Chatwoot registers.
• Wrong callback path / reverse-proxy mismatch — nginx, Traefik, or folder installs rewrite the webhook URL so Meta’s challenge never reaches Chatwoot.
• Firewall / IP drops — hosting panels that block Meta verification after Chatwoot “saved” a green URL.
• Channel subscribed fields missing — Page/IG/WhatsApp channel looks connected in UI, but subscribed webhook fields never fire when the reviewer sends a test message.
• Staging vs production App ID confusion — screencast uses production; reviewer credentials open a staging Chatwoot with a different Meta app or callback.

For a Chatwoot app review, fix HTTPS webhook reachability and channel connect before rewriting permission essays. Publishing/cron diagnosis belongs to Stackposts; here the failure mode is usually webhook → inbox event, not schedule → publish.

Why Chatwoot app review gets rejected

• Product tour without inbox proof — teams, labels, and automation shown; no recording of Login → channel connect → a live Messenger, Instagram, or WhatsApp message landing in Chatwoot.
• Scope inflation — ads, publish, or unused WhatsApp surfaces requested “because Chatwoot can integrate,” while the live demo only opens a Page Messenger thread.
• Admin-only success — owner channels work; Test User / reviewer never gets a Page, IG professional account, or WhatsApp test asset Chatwoot can inbox.
• Use-case vs policy stretch — notes imply spammy outreach or unclear customer value; Meta reads disallowed messaging patterns.
• Screenshot theater — stills of an unread badge without a recreateable connect + inbound/outbound flow.
• Business Manager / verification gaps — app under a BM that cannot support the access level for messaging APIs.

Banner labels vary (“unable to verify the permission(s) requested,” “inadequate demonstration,” “disallowed use case”). Map the banner to missing Chatwoot inbox evidence — not to a luckier resubmit day. Related: Unable to Verify Permissions, Inadequate Demonstration, Disallowed Use Case.

pages_messaging, Instagram, and WhatsApp in one Chatwoot package

Many Chatwoot Meta submissions request pages_messaging, instagram_manage_messages, and whatsapp_business_messaging because agencies run one shared inbox across channels. That is valid when each channel is live — but each still needs recreateable proof. A clean Messenger thread does not automatically prove Instagram DM behavior or WhatsApp Cloud messaging into Chatwoot.

If Instagram or WhatsApp is unfinished on your install, drop that scope from the Chatwoot app review round instead of hoping Meta will approve “the Messenger half.” Narrower, honest packages beat a maximal Meta checklist copied from another seller’s screencast. This guide does not cover WhatsApp template rejection appeals or phone-already-registered operations — those sit outside this App Review diagnosis service.

Chatwoot vs Stackposts and ChatPion/BotSailor (keep Category B lines separate)

Chatwoot fails on omnichannel inbox webhooks and channel connect proof. Stackposts fails on publishing scopes and scheduler recreateability. ChatPion and BotSailor fail as white-label chatbot SaaS stacks with bot-flow proof needs. Mixing those narratives in one Meta submission confuses reviewers. Keep this Chatwoot app review package focused on Messenger / Instagram / WhatsApp inbox channels you enabled. If you also run a scheduler or chatbot script on the same BM, treat it as a separate app and separate review story whenever possible.

Common Chatwoot demo gaps (diagnosis, not secret sauce)

• Instructions that assume the reviewer already knows Chatwoot inboxes, channel settings, and agent assignment UI.
• Test Page / IG / WhatsApp asset not granted to the credentials you supplied.
• Screencast jumping past Facebook Login / channel grant into a pre-connected inbox.
• Webhook “verified” in settings but no inbound event when the reviewer messages the channel.
• Privacy Policy / data deletion URL on a different domain than the Chatwoot app Meta sees.

Self-hosted domains, Docker vs bare-metal, and multi-account models differ — copying another agency’s Chatwoot app review recording usually creates a new mismatch.

When a Chatwoot specialist audit helps

For a sister open-source scheduler (publish scopes, not inbox webhooks), see the Postiz app review guide. If the rejection is really about creating or managing ad campaigns rather than Chatwoot channels, switch to the ads_management App Review diagnosis — inbox proof will not clear Marketing API write access.

Useful after one or two Chatwoot app review rejections when the inbox “works for you” but Live reviewers still cannot recreate messaging. A specialist Chatwoot app review audit maps rejection language to evidence gaps: HTTPS callbacks, Page/IG/WhatsApp channel connect, which Meta messaging scopes need Advanced Access, and Business Verification blockers.

Not useful if you only want a guaranteed one-size recording or every Meta permission enabled “just in case.” Over-requesting increases failure surface. For installation + omnichannel approval service framing, see Chatwoot App Approval.