15 Meta Permissions Approved for a WhatsApp Sales Automation SaaS — After a Screencast Language Rejection
The founder of a WhatsApp sales automation platform for Latin American businesses — a ManyChat-style tool combining WhatsApp Cloud API messaging, Meta Ads reporting, AI-based payment verification, and Instagram/Facebook DM automation — needed 15 Meta permissions approved before the product could go live for paying customers. Business Verification was already done and Access (Tech Provider) Verification was already submitted before this project started.
This is what the submission actually required, why one shared rejection reason knocked out three permissions on the first attempt, and how the resubmission got all 15 approved.
The starting situation
One of the widest permission sets
WhatsApp Cloud API messaging and management, Meta Ads reporting, Page and Instagram messaging, and comment moderation — 15 permissions requested together in one submission.
Verification already in progress
Business Verification was complete and Access (Tech Provider) Verification was already submitted, so app-role and Business Manager access had to be planned around that existing state, not from scratch.
Access kept scoped, not wide open
The client did not want to hand over full Business Manager admin access. Getting the right role — Admin in the app, and Business Manager access limited to only that one app as an asset — took a few rounds of back-and-forth.
A live product, not a mockup
Screencasts needed a real connected WhatsApp Cloud API number, real ad campaigns, and real Facebook/Instagram comments — not placeholder data.
What actually had to be approved
A WhatsApp-first sales automation SaaS needs a wide spread of permissions across four different systems — WhatsApp, Meta Ads, Pages, and Instagram — each reviewed on its own:
Each one needs its own usage description and its own moment in the screencast. Meta reviews them together as one submission, so a weak demonstration on any single permission can hold back the rest.
Why this kind of project fails when done alone
Non-English interface
The product's dashboard is built for a Spanish-speaking market. A reviewer has to be able to follow every screen — a working feature shown in an unreadable interface still gets rejected.
Development-mode limits
Meta does not deliver real webhook events — comments, messages — to an unpublished app the same way it does once the app is Live, even for admins. Screencasts have to be planned around that, not against it.
Nothing for the reviewer to see
A demo account with no ad campaigns, no connected WhatsApp number, or no incoming messages leaves a reviewer with nothing to verify — even if every feature genuinely works.
Comment permissions need real proof
pages_manage_engagement and instagram_manage_comments cover replying to, hiding, and deleting real user comments — not publishing new posts. The demonstration has to match what the product actually does.
How the project was handled (high level)
Access & scope setup
Agreed the minimum access needed to actually run the submission: Admin role in the Meta app, and Business Manager access scoped to only that one app as an asset — not full Business Manager control.
Reviewer-readiness pass
Worked through the live platform as a reviewer would. A dashboard crash triggered by browser auto-translate was fixed, the interface was confirmed to display correctly in English, and test data was set up so the Ads, Messenger, and Instagram sections all had something real for a reviewer to see.
Submission
Usage descriptions and screencasts covering all 15 requested permissions were prepared and filed as one submission.
First review result
Meta approved 12 of the 15 permissions. The remaining 3 — pages_read_user_content, pages_manage_engagement, and instagram_manage_comments — were rejected for one shared reason: the screencast was recorded in Spanish with no English overlays.
Correction & resubmission
The comment-management flow was re-recorded with the interface translated to English and each action labeled on screen — reading, replying to, hiding, and deleting comments on both Facebook and Instagram. Resubmitted under the free resubmission included in the project.
The result
All 15 permissions approved. The client's WhatsApp sales automation, Meta Ads reporting, and Facebook/Instagram messaging and comment tools could finally go live for real customers.
Common reasons this type of submission gets rejected
- A screencast recorded in a non-English interface with no English captions or overlays gets rejected even when the feature works correctly.
- Comment and engagement permissions need a real read, reply, hide, delete flow shown on the live post — not a scripted publish-and-comment demo.
- A reviewer test account with no ad campaigns, no live WhatsApp number, or no incoming messages leaves reviewers with nothing to verify.
- Development-mode apps do not receive real webhook events for comments or messages, even for admins — the screencast plan has to work around that limitation.
- Business Manager access that is too narrow can block the person actually filing the submission, while access that is too wide raises the client's own security risk — getting the scope right matters on both sides.
If your SaaS platform needs WhatsApp Business API, Meta Ads, and Facebook/Instagram permissions approved together — or a screencast was rejected over language or demo issues — this is exactly the kind of project we handle. See our WhatsApp App Review service or our Instagram screencast rejection case study for more.