Your Meta App Review Was Rejected — Here Is Every Reason Why It Happens
Meta sends a rejection notice with a reason code. But reason codes alone rarely explain what actually needs to change — or how many other failure points are lurking in the same submission.
Meta App Review has over 20 named rejection codes across 6 distinct categories. Most developers fix the obvious issue, resubmit, and get rejected again — for a different reason that was always there. Rejection is not the only way to lose access, and our Meta app restricted or disabled appeal process guide covers enforcement and how the appeal actually works. This happens because the review evaluates your entire submission in a single pass. One category failing means every permission in that submission is rejected, and the 2–7 business day clock resets from zero.
20+
Named rejection codes in official Meta documentation
6
Rejection categories evaluated in every submission
1
Failed category = full submission rejected & clock reset
Category 1 — App Accessibility & Testing Environment
⚠ Your app is not loading during testing (Web / Android / iOS)
Reviewers use the app URL or APK/Simulator Build in your verification details. If they cannot load the app from an external network, the entire submission is rejected — not just the inaccessible platform. A URL that works inside your office VPN but nowhere else is a guaranteed rejection.
⚠ The test credentials that you provided do not work
Apps without Facebook Login must supply working non-Facebook test account credentials. If those credentials fail from outside your network — wrong password, expired session, IP restriction — every permission in that submission cannot be verified and is rejected.
⚠ Your app does not accurately reflect the final user experience
App Review should only be requested for apps ready to switch to Live Mode. If any feature is still under development, a flow is incomplete, or the app has placeholder screens at the time of submission, rejection is automatic. Submitting early to “test the process” wastes review cycles and delays the product.
Category 2 — Screencast & Demo Video
⚠ We are unable to verify the permission(s) requested while testing your app
Reviewers use the screencast as a guide and attempt to reproduce the exact same flow. If they cannot replicate what the video shows — wrong test user credentials, flow broken at a step, a feature not yet built — every unverified permission is rejected. This is the single most common rejection code across all submission types.
⚠ Unable to locate Facebook Login Button while testing your app
If the Login button is buried, conditionally shown, or not findable following your own written testing instructions, the submission is rejected outright. The button must be visible at the exact step described in your App Verification Details.
⚠ Your app’s Facebook Login Button is broken
Button visible but non-functional — OAuth errors, wrong App ID wired to the Login button, redirect failures, or cookie/session issues. A broken login means zero permissions can be verified. This is also one of the hardest rejections to diagnose remotely.
⚠ We Were Unable to Test the Steps to Connect an Instagram Business Account
For Instagram Graph API permissions, reviewers must be able to sign in and connect a Professional Instagram account through the app. If the connection flow breaks at any step — even one OAuth redirect mismatch — all Instagram permissions in that submission are rejected.
Category 3 — Permission & Policy Violations
⚠ Your app violates Platform Policy 8.9 — Minimum Permissions
Requesting data you do not actively use to improve the user experience violates the minimum permissions principle. If Meta cannot see a clear, demonstrated user benefit for each permission in the app, that permission is rejected. Developers often request permissions “just in case” or for planned future features — both are consistent rejection causes.
⚠ Your app incentivizes unapproved actions
Any reward system for Instagram likes, follows, shares, or other platform actions violates Instagram Platform Policy A.30. Apps in the analytics, growth, scheduling, or engagement tool space frequently trigger this rejection — particularly if the business model involves any form of incentivized engagement.
⚠ Page Public Content Access not needed based on your submission details
PPCA has a narrow, specifically defined allowed use case: analyze and display posts and engagement on Pages. Submissions that do not demonstrate this exact use case are rejected, regardless of how strong the rest of the submission is.
⚠ Disallowed use case details
The reviewer concludes your described use case does not align with the allowed purposes for the requested permission — or that the feature could be misused even if you claim it will not be. Wording precision matters as much as technical correctness. A vague or broad use case description is treated the same as a prohibited one. Publishing and reply permissions such as threads_content_publish need review before real users can grant them, and our Threads API App Review guide covers where submissions stall.
Category 4 — Compliance Gaps
⚠ Privacy Policy — Missing, Unreachable, or Insufficient
Every app handling Facebook user data requires a publicly accessible HTTPS privacy policy URL. The policy must cover what data is collected for each specific permission requested. A generic policy that does not mention the scopes, a URL behind a login wall, or a URL returning a 404 are all automatic rejections. This is one of the most frequently missed requirements. A live app can be disabled without any new submission, which is what the annual Data Use Checkup deadline catches many teams with.
⚠ Data Deletion Callback URL or Instructions URL — Missing
Apps using Facebook Login or handling user data must have a valid data deletion mechanism configured in the App Dashboard under Facebook Login Settings. If the URL is missing, broken, or points to a non-functional endpoint, App Review flags it as a compliance failure — even if reviewers do not explicitly name it in the rejection reason.
⚠ Business Verification not completed (required for Advanced Access)
Advanced Access permissions require the app’s linked Business Portfolio to be Meta Business Verified. If Business Verification is pending, under review, or rejected at the time of App Review submission, Advanced Access permissions cannot be approved — regardless of how strong the screencast, privacy policy, and use case justification are.
Category 5 — Branding & Identity Violations
⚠ Your app is using Facebook’s Company Brand in a way that is not permitted
App names, icons, or descriptions that imply official partnership with or endorsement by Meta/Facebook — or names that resemble Meta products (e.g., “FBTool”, “InstaBoost”, “MetaHelper”) — are rejected. The app name and icon must be uniquely yours and must not imitate any Meta brand asset.
⚠ Your app violates Developer Policy 1.7 — Deceptive or Misleading
The app’s display name, icon, or submission description does not match the actual experience reviewers find when testing. This gap — between what you say the app does and what it actually does — is treated as deception under Policy 1.7, regardless of whether the mismatch was intentional.
⚠ Your app provides users with assessments that are not approved
Personality predictions, behavioral tendency assessments, compatibility tests, or apps offering minimal utility fall under the “minimal utility” violation. This affects a wider range of apps than most developers expect — particularly SaaS tools that include any engagement-scoring or user analysis features.
Category 6 — App Mode & Development Readiness
⚠ App submitted while still in Development Mode
Permissions work for test users in Development Mode but are locked for real users in Live Mode. Submitting for App Review does not switch your app to Live Mode — you must be ready to switch to Live Mode at the time of submission. A common and costly mistake: developers submit from Development Mode expecting App Review to “unlock” their app for all users. It does not work that way.
⚠ No API calls made using the requested permission within 30 days
Meta requires at least one successful API call using each permission for which Advanced Access is being requested within 30 days of submission. Zero usage signals the permission is not yet needed — or the feature is not yet built — and the submission will be rejected or deprioritized.
⚠ Your canvas app redirects users off Facebook / Login embedded in a web view
Canvas apps whose primary purpose is to redirect users away from Facebook violate Platform Policy. Separately, mobile apps that display Facebook Login inside an in-app web view (rather than the system browser) are rejected because the web view cannot share cookies with the browser — resulting in a broken experience Meta will not approve.
Every resubmission resets the clock. Meta reviews the full submission in one pass. If your screencast is perfect but your privacy policy URL is broken, every permission in that submission is rejected — and the 2–7 business day review window starts again from zero. The majority of first-time submissions fail across multiple categories simultaneously. Fixing one and resubmitting means waiting through the full review window again — for each round.
Get It Right Across All Six Categories
Clearing every rejection category simultaneously requires preparing the screencast, privacy policy, data deletion URL, Business Verification, App Dashboard configuration, use case justification, and submission wording in parallel — before the first submission. One gap restarts the process. This is what the service covers: end-to-end submission preparation aligned with what Meta reviewers actually check.
Meta makes all App Review and permission approval decisions independently. Rejection reasons, review timelines, and approval outcomes are determined solely by Meta’s review process and cannot be influenced or guaranteed by any third party. This post draws on official Meta developer documentation and is intended for informational purposes only. It does not represent an official Meta publication, nor is any service offered here provided in partnership with or endorsed by Meta.