If you are building an app that publishes posts, reads engagement data, or moderates comments on Facebook Pages you do not personally own, you need a set of permissions that Meta will not grant by default.

The core Facebook Page API permissions — pages_manage_posts, pages_read_engagement, pages_show_list, and others in the cluster — all require a full Facebook App Review before your app can use them on real client Pages.

Standard Access works temporarily while you test with Pages your own test users administer. The moment your app needs to access or manage a Page that belongs to a client or subscriber, every permission needs Advanced Access — and Advanced Access means passing App Review.

The Facebook Page API permission cluster

Meta documents the fields and edges for these objects in its Pages API reference. Check each name against that reference before you list it in a submission, because a mismatch between the request and the screencast is a common cause of rejection.

Meta's pages_read_engagement permission description is specific: it lets your app read content (posts, photos, videos, events) posted by the Page, read followers data (including name and PSID) and profile picture, and read metadata and other insights about the Page, to help a Page admin manage it. The pages_show_list permission has no dependencies; it lets your app show a person the Pages they manage and verify that they manage a Page.

Who gets blocked by these permissions

Any app that works with Facebook Pages on behalf of someone else — a client, a subscriber, a business owner — runs into this gate.

The most common affected projects include social media scheduling and bulk publishing tools, agency dashboards managing multiple client Pages, Page analytics and performance reporting platforms, community management and inbox moderation tools, and SaaS platforms integrating Facebook Page posting through the API.

The pattern is always the same: the app works in development while the developer's own test Pages are connected. The first real client connects, Standard Access stops working, and the developer discovers that Advanced Access — gated behind App Review — is the only path forward.

What App Review actually involves for Page permissions

1. Select the use case and request only what you need

   In Meta's App Dashboard under App Review, select the use case that matches your product. Each use case bundles a set of permissions. Only request permissions your app genuinely uses — Meta's reviewers will check each one against your screencast. Unverifiable permissions trigger rejection for the full submission.

2. Write a specific use case justification per permission

   For each permission, Meta requires a written explanation of exactly how your app uses it, what user benefit it enables, and how the data is handled.

   Generic answers like “we post content to Pages” fail. Reviewers need to understand the specific user flow, what action the permission enables, and what happens to the data after it is accessed.

3. Record a screencast for every permission requested

   A video demonstration is required for every permission. The recording must show a complete, working user flow: a test user with actual Page admin role, granting the permission, navigating to the specific feature, and the permission performing the exact function stated in the justification.

   A single missing step — an unshown permission grant, an incomplete flow — means rejection for that permission.

4. Complete Meta Business Verification first

   Advanced Access for all Facebook Page API permissions requires a verified business in Meta Business Manager. Meta Business Verification is a separate, multi-step process that must be completed before App Review can grant Advanced Access. An unverified business cannot receive Advanced Access regardless of how strong the App Review submission is.

5. Make the app fully accessible to reviewers

   Meta will attempt to access and test the app directly during review. If the app is behind a login wall they cannot pass, a staging environment that is offline, or a URL that returns an error, the entire submission is rejected. The app must be live and publicly testable at the time of submission.

6. Submit, monitor, and handle rejections per permission

   After submission, Meta reviews the use case, justification, and screencast for each permission individually. Typical review times run 2–7 business days. A rejection on any single permission requires a corrected resubmission and resets the review clock for that permission. Complex submissions covering five or six Page permissions regularly take longer than first-time developers expect.

Each rejected permission is a 2–7 day resubmission cycle. A tool requesting five Page permissions that gets one rejection per permission can spend six to eight weeks in review before the app is fully cleared for real client use. The preparation quality before the first submission determines how many of those cycles you face.

Plan the screencast before you write the justification. Start with the test user who holds the admin role on the business asset, show the login and the selection step, then show the one feature that reads or writes each object in the flow.

Reviewers test the flow the video shows, so every claim in the written text needs a matching moment on screen. If a scope is used only in a background job, record the effect in the dashboard instead of showing code.

Keep the test environment honest. Use a test asset you control, with real content, and make sure the reviewer account can reach every screen in the recording without special steps.

An empty profile with no posts or followers makes engagement features look untested, even when the code is correct. Remove test data that is not needed, and keep the public URL reachable for the whole review window.

Finally, check the wording against the code. Each justification should name the feature, the user, and the data touched, and nothing more.

Remove any sentence that describes a feature the app does not ship yet. Reviewers compare the text with the live product, and a claim that cannot be demonstrated tends to get the whole submission returned.

Common reasons Facebook Page API submissions get rejected

• Requesting pages_manage_posts or pages_manage_engagement when only read operations are shown in the screencast — submission and video must match exactly.
• Screencast uses a personal profile or Business Manager preview rather than a test user with actual Page admin role — Meta cannot verify the permission grant flow.
• Use case justification is too generic without describing the specific user workflow, data handling, and end-user benefit per permission.
• App is behind a login screen, staging password, or non-public URL — Meta cannot test it and rejects the whole submission.
• Business Verification not completed before submitting for Advanced Access.
• Requesting pages_show_list without showing a feature that actually uses the returned Page list in the screencast.
• Privacy policy does not reference the specific data types collected via Page engagement and user-generated content permissions.
• Requesting the full use-case permission bundle including pages_manage_engagement when the app only needs to publish — unused permissions in the bundle are tested individually.

FAQ

Note: Meta makes all App Review and permission approval decisions independently. Review timelines and outcomes depend entirely on Meta’s process and cannot be guaranteed by any third party.

This post describes the App Review preparation and submission process based on publicly available Meta developer documentation — it is not an official Meta service or partnership, and no approval outcome can be guaranteed.

Related: What is Meta Advanced Access — explaining the difference between Standard and Advanced Access and why it gates Page API permissions; the Meta App Review rejection fix service for apps already in a rejection cycle; and the full Facebook App Review service for done-for-you submission support across all Page permissions.