Integrations10 min read·July 24, 2026

Facebook App Review RejectedCommon Reasons and Fixes

Meta Graph APIFacebook LoginNext.js

Meta's app review process rejects applications with error messages that rarely indicate what actually needs to change. This post documents the real reasons apps get rejected, what the review team looks for in screencasts, and the exact configuration changes that lead to approval.

Problem Summary

You have built an application that integrates with Facebook via the Meta Graph API. You have created a Meta Developer app, added the required permissions in the App Review section, recorded a screencast demonstrating the feature, and submitted for review. Days later you receive a rejection notification in the Meta Developer Console. The reason is brief and often circular: 'The reviewer was unable to complete the review because the use case was not demonstrated.' You re-record the screencast, resubmit, and receive the same rejection.

Symptoms

App Review status shows 'Rejected' with a reason like 'Unable to verify use case' or 'Incomplete submission'
Permissions requested appear in the app but users cannot grant them because the app is in development mode
The screencast submission link fails to load or the uploaded video was rejected for format
Meta sends a rejection citing a missing 'Data Use Checkup' or 'Data Deletion Callback URL'
The app has been in Development mode for months with only manually added test users
Permissions like pages_manage_posts or instagram_content_publish show as 'Not Approved' in the App Dashboard
The app works perfectly for the developer account but fails for any other user
Review rejection emails include a reference ID but no thread to reply to for clarification

Business Impact

Facebook apps in Development mode are restricted to users with specific roles in the Meta Developer account: Admin, Developer, and Tester. Any external user who attempts to use the app's Facebook Login or Graph API features sees an error or cannot grant permissions. This makes the app impossible to ship. For social media management tools, publishing integrations, or apps that require managing Facebook Pages, the entire product category is blocked until review passes.

Root Cause

Meta's app review is a human review process where a contractor attempts to use your app following the steps provided in your submission notes. If the reviewer cannot log in, cannot find the feature that requires the permission, or cannot complete the workflow end-to-end using the test credentials you provided, the submission is rejected as 'unable to verify.' The root cause of most rejections is that the submission package notes, screencast, and test credentials does not give the reviewer everything needed to independently reproduce the workflow.

⚠

Meta's review team cannot see your application's source code or backend. They interact entirely as an end user. If any step in the workflow requires prior context, a specific URL, an invite link, or credentials that were not provided in the submission notes, the review will fail. The screencast is not a substitute for working test credentials both are required.

Diagnosis

Step 1: Verify App Settings Are Complete Before Submission

Before any App Review submission, your Meta app must have all required platform settings filled in. Navigate to App Dashboard > Settings > Basic and verify every required field. Missing fields in Basic Settings cause automatic rejection.

App Icon (1024x1024 PNG, no transparency)
Privacy Policy URL publicly accessible, on your domain
Terms of Service URL
App Category
Business Use (if the app accesses business-managed Pages or Instagram accounts)
Data Deletion Request URL or Data Deletion Instructions URL

Step 2: Request Only Necessary Permissions

In the App Review section, each permission requires a separate use case justification. Requesting a permission without a clear demonstrated use case in the screencast is a rejection. Audit your permission requests against your actual feature set.

Minimal Facebook Login scope example

// Only request what you need at the point of use
// Bad: requesting everything upfront
FB.login(callback, {
  scope: "email,public_profile,pages_manage_posts,pages_read_engagement,publish_actions"
});

// Good: request basic permissions at sign-in, then request additional
// permissions only when the user accesses the feature that requires them
FB.login(callback, {
  scope: "email,public_profile"
});

// Later, when user accesses the "Post to Page" feature:
FB.login(callback, {
  scope: "pages_manage_posts,pages_read_engagement",
  auth_type: "rerequest"
});

Step 3: Prepare the Screencast Correctly

The screencast is the most important part of the submission. It must show the complete end-to-end user journey from login to the point where the requested permission is used. Meta rejects screencasts that are too short, too fast, skip steps, show a development environment (localhost), or demonstrate the feature on the developer's own account without showing the permission grant dialog.

Record at 1080p, minimum 720p blurry screencasts are rejected
Show the Facebook Login dialog with the permission grant screen
Show the feature that uses the permission working after the grant
Use a test account that is NOT the developer account Meta reviewers check this
Record the app on your production URL (https://yourapp.com), never localhost
Include audio narration explaining each step reviewers cannot read your mind
Maximum video length: 10 minutes. Most successful screencasts are 3-5 minutes.

Step 4: Provide Complete Test Credentials

In the submission notes, provide a dedicated test account that the reviewer can use. This account must be a Tester role in your Meta Developer app, must have the minimum setup required to use the feature (e.g., a Facebook Page must already be connected), and must work end-to-end without requiring any additional setup by the reviewer.

App Review submission notes template

## Test Account Credentials
- Email: reviewer@yourtest.com
- Password: TestPassword123!
(This account has the Tester role in the app and is pre-configured with a test Page)

## Step-by-Step Instructions
1. Go to https://yourapp.com/login
2. Click "Continue with Facebook"
3. Grant the requested permissions on the Facebook dialog
4. You will land on the dashboard at /dashboard
5. Click "Connect a Page" in the left sidebar
6. Select "Test Company Page" from the list
7. Click "Post Update" and enter any text
8. Click Publish  the post will appear on the test Page

## What permission this demonstrates
pages_manage_posts: Used in Step 7 to publish content to the connected Page.
The test Page "Test Company Page" is already connected to the test account.

Step 5: Complete the Data Handling Questionnaire

Meta requires apps to complete a Data Use Checkup every year and to provide a Data Deletion callback. Navigate to App Dashboard > App Review > Permissions and Features and check whether any permission shows a 'Complete Data Use Checkup' requirement. Failing to complete this blocks the permission from being approved regardless of screencast quality.

# Data Deletion Callback URL must respond to HTTP GET with JSON:
# GET https://yourapp.com/api/facebook/data-deletion
# Response: { "url": "https://yourapp.com/data-deletion-status?code=USER_CODE", "confirmation_code": "USER_CODE" }

Production Failure Scenarios

Scenario 1: App Switched to Live Mode Before Review Completes

A developer switches the app from Development mode to Live mode expecting this to make it publicly accessible while review is pending. In Live mode, the app CAN be used publicly, but only with default permissions (email, public_profile). Any permission that has not been approved by App Review still requires users to have a Developer or Tester role. The reviewer uses a standard Facebook account without those roles and cannot grant the unapproved permissions, causing immediate rejection.

Scenario 2: Test Facebook Page Has Restrictions

The test Facebook Page provided to the reviewer has age restrictions or geographic restrictions enabled. The reviewer's account does not meet those restrictions and cannot see the Page in the permission grant flow. The app appears to not demonstrate the use case. Fix: use an unrestricted Page for review testing and add a note in the submission that the feature supports restricted Pages.

Scenario 3: Deprecated Permission Requested

An app requests publish_actions, a permission deprecated in Graph API v3.0 (2018) and no longer available. The App Review interface still allows selecting it, but the reviewer immediately rejects any submission containing deprecated permissions. Always cross-reference your permission list against Meta's changelog at developers.facebook.com/docs/graph-api/changelog.

Prevention Checklist

Complete every field in App Dashboard > Settings > Basic before submitting for review
Implement and test the Data Deletion Callback URL before submission
Record the screencast on the production URL, not localhost or a staging subdomain
Use a Tester-role Facebook account (not the developer account) for all screencast recording
Pre-configure the test account so the reviewer can complete the workflow in under 5 minutes
Include detailed step-by-step instructions in the submission notes assume the reviewer has never seen your app
Cross-reference every requested permission against Meta's Graph API changelog to confirm it is not deprecated
Request permissions progressively (at the feature level) rather than all upfront at login
Complete the Data Use Checkup for all permissions that require it before submitting

Resolution Summary

The repeated rejections were caused by: an incomplete Data Deletion Callback URL (not implemented at all), a screencast that showed the feature on the developer's own admin account (not a standard user account), and submission notes that did not provide working test credentials. After implementing the deletion callback, re-recording the screencast with a Tester account, and writing detailed step-by-step submission notes with login credentials, the review passed on the next submission.

Lessons Learned

Treat the App Review submission like a QA bug report give the reviewer everything they need to reproduce the workflow independently
The Data Deletion Callback is not optional; it must be implemented and the URL must return the correct JSON structure
Never use your own developer account in the screencast use a separate test account with Tester role
Each permission needs its own demonstrated use case in the screencast a single walkthrough that touches all features is not enough if each permission is not explicitly shown being used
Read Meta's Platform Policy update emails carefully deprecated permissions and new data handling requirements are announced there before affecting app reviews

Conclusion

Meta App Review is an opaque process, but it follows a consistent pattern: reviewers need to independently replicate your feature using your submission notes and test credentials. Every rejection is ultimately because the reviewer could not complete that replication. Invest time in your submission notes and screencast narration rather than in resubmitting the same package repeatedly.

Nurture Technologies

NEED HELP WITH YOUR STACK?

Nurture Technologies builds and maintains production-quality software for startups and businesses. If engineering problems are slowing you down, our team can help.

Talk to our team →

FAQ

FREQUENTLY ASKED QUESTIONS

How long does Facebook App Review take?+

Meta states the review process takes up to 5 business days, but in practice it often takes 7-14 days for complex permissions. Business verification (required for certain scopes) adds additional time. Resubmissions after rejection restart the timer. During high-volume periods (Q4, major platform announcements) reviews can take 3-4 weeks.

What is the difference between Development mode and Live mode in Meta apps?+

In Development mode, only users with App roles (Admin, Developer, Tester) can use the app's Facebook Login and Graph API features. External users receive an error. In Live mode, the app is publicly accessible, but only with default permissions (email, public_profile). Permissions that have not been approved by App Review are still restricted to role users even in Live mode.

Do I need to resubmit for review if I add a new permission after approval?+

Yes. Each permission requires its own App Review approval. Adding a new permission after your initial approval requires a new submission with a screencast demonstrating the new permission's use case. Previously approved permissions do not need to be re-demonstrated, but they must remain in your app's configuration.

What is the Data Deletion Callback URL and what must it return?+

The Data Deletion Callback URL is an endpoint that Meta calls when a user requests deletion of their Facebook data. It must accept an HTTP POST request with a signed_request parameter, verify the signature using your app secret, parse the user ID, delete or queue for deletion all data associated with that user, and return JSON containing a confirmation_code and a status URL: { "url": "https://yourapp.com/deletion-status?code=UNIQUE_CODE", "confirmation_code": "UNIQUE_CODE" }.

Can I use Meta's test users instead of a real Facebook account for the screencast?+

Yes, and this is the recommended approach. Create a test user in App Dashboard > Roles > Test Users. Test users are Facebook accounts created specifically for app testing that are not real people. They have Tester role by default, can accept permission grants, and can be configured with test Pages and Instagram accounts. Using test users avoids privacy concerns with exposing real user data in screencasts.

My app was approved but a specific permission keeps showing 'Not Approved' why?+

Individual permissions within a submission can be approved or rejected independently. If a permission shows 'Not Approved' after an overall submission approval, it means the reviewer approved the app but rejected that specific permission. You need to submit a separate App Review request specifically for that permission with a new screencast demonstrating its use case.

What happens to my approved permissions if I change the app's category?+

Changing the app category in Basic Settings can trigger a re-review of all existing permissions. Meta's systems flag category changes as potentially indicating a change in app purpose. To be safe, contact Meta developer support before changing the category of an app with approved permissions.

Does my app need Business Verification to pass App Review?+

Some permissions require Business Verification specifically permissions related to managing Facebook Pages, Instagram Business accounts, and advertising accounts on behalf of other businesses. Navigate to Business Settings in Meta Business Manager to start the verification process. Business Verification requires a business registration document or phone number verification and typically takes 2-5 business days.

Can I submit multiple permissions in one App Review request?+

Yes. In App Dashboard > App Review > Permissions and Features, you can select multiple permissions and submit them together. Each permission still needs its own use case justification and demonstration in the screencast. A single screencast that clearly shows each permission being used is acceptable. However, if one permission's use case is unclear, the entire submission may be rejected consider submitting permissions in smaller batches to isolate failures.

What is the fastest way to get back to reviewers after a rejection?+

There is no direct communication channel with Meta's review team you cannot reply to rejection notifications. The only recourse is to fix the identified issues and resubmit. If the rejection reason is unclear, post in the Meta Developer Community forums (developers.facebook.com/community) with your app ID and rejection reason. Meta Developer Support via the Support Inbox in the Developer Console can sometimes provide clarification but response times vary.