Our Meta app review failed.
Then it failed again.
And again. And again. Five times in six weeks.
The application worked perfectly every time we tested it. Webhooks fired. Tokens refreshed. Instagram insights loaded. The OAuth flow was clean. We had followed the documentation. We had tested every edge case. The code was not the problem.
The reviewers still rejected it.
If you have built a Meta integration Facebook Login, Instagram Graph API, Instagram Messaging API, WhatsApp Business API you have probably felt this. The review process is opaque, the rejection messages are vague, and re-submission feels like shouting into a void. Every rejection resets the clock. Every round trip costs days. And the rejection reasons often do not tell you what actually went wrong.
This is the post we wish had existed when we were going through it. Not a walkthrough of the API. A walkthrough of the review process every mistake we made, why it failed, and what actually fixed it.
Our Environment
We were building a SaaS product for businesses to connect their Instagram Professional Accounts and automate customer-facing workflows: responding to DMs, routing conversations, scheduling posts, and surfacing engagement analytics in a unified dashboard.
- Frontend: Next.js with Facebook Login via OAuth 2.0, a connected accounts settings page, and an Instagram analytics dashboard
- Backend: NestJS with a dedicated Meta integration module handling token exchange, refresh, and webhook processing
- Integrations: Facebook Login (for authentication), Instagram Graph API (insights, media, content publishing), Instagram Messaging API (DM automation), Meta Webhooks (real-time message and comment events)
- Business context: end users are small-to-medium businesses connecting their own Instagram accounts
The permissions we needed spanned multiple review categories. Facebook Login required one submission. Instagram Graph API permissions required a separate submission. Instagram Messaging required another. Each had different review requirements, different documentation, and different timelines. We did not fully understand this separation at the start, which made the early failures worse.
First Rejection: Insufficient Instructions
Three days after our first submission, the rejection arrived: 'We were unable to reproduce the feature described in your submission. Please provide detailed step-by-step instructions so our review team can test your app.'
We read that and thought: we submitted instructions. We submitted a description. We submitted screenshots. We did not understand what was missing.
What was missing was everything the reviewer needed to actually test the app without knowing anything about it.
Mistake #1: Assuming Reviewers Understand the Application
Meta reviewers are not your users. They are not technical evaluators who will dig through your app to understand how it works. They are reviewers with a queue of submissions to get through. They will spend a fixed amount of time on your submission, follow the instructions exactly as written, see what they see, and move on.
If your instructions are incomplete, they will not figure out the missing step. They will reject and close the ticket.
Our original instructions looked like this:
How to test: Instagram Insights permission
1. Log into the app with Facebook.
2. Connect your Instagram account.
3. View your analytics dashboard.
Expected result: Analytics data appears.After the first rejection we rewrote them completely:
Permission: instagram_manage_insights
Use case: Display Instagram Professional Account analytics to business owners.
--- TEST ACCOUNT CREDENTIALS ---
Test Facebook account: reviewer.test@nurturetech.dev
Password: MetaReview2026!
This account has been pre-configured with:
- A Facebook Page named "Nurture Test Business"
- A connected Instagram Professional Account with 90 days of post history
- 30+ test posts with engagement data
--- STEP-BY-STEP INSTRUCTIONS ---
Step 1: Navigate to https://app.nurturetech.dev/login
Step 2: Click the blue "Continue with Facebook" button
Step 3: On the Facebook permission dialog, approve ALL requested permissions
(click "Continue" on each screen do not skip any)
Step 4: After redirect to the dashboard, click "Settings" in the left sidebar
Step 5: Click "Connect Instagram Account" under the Integrations section
Step 6: Select "Nurture Test Business" from the account dropdown
Step 7: Click "Connect" you will be redirected to Facebook permissions again
Step 8: Approve the Instagram permissions and return to the dashboard
Step 9: Click "Analytics" in the top navigation bar
Step 10: Select date range "Last 30 Days" from the dropdown
--- EXPECTED RESULT ---
A dashboard showing:
- Total followers: ~1,200
- Post reach (last 30 days): chart with daily data points
- Engagement rate: percentage displayed per post
- Top 5 performing posts with thumbnail and metrics
If the dashboard shows a loading spinner for more than 10 seconds,
please try refreshing the page. Data loads from Instagram's API
and may take 5-10 seconds on first load.Write review instructions as if you are onboarding someone who has never heard of your product, has ten minutes to test it, and will not ask you any questions. Account for every click, every permission dialog, every redirect, and every expected result. Over-specify. You cannot be too detailed.
Second Rejection: Reviewer Lacked Permissions
We rewrote the instructions and resubmitted. New rejection: 'The test account provided does not have the required access to test this feature.'
The test account we had created was a regular Facebook personal account with a personal Instagram account linked to it. We had tested with it internally and everything worked. But Meta's review infrastructure and the permissions required to test advanced Graph API features requires a specific type of account setup that a personal account cannot provide.
Mistake #2: Using the Wrong Test Account Structure
For most Facebook Login permissions, a test Facebook user account is enough. For Instagram Graph API permissions insights, messaging, content publishing you need a full professional account stack. A personal Instagram account does not qualify for Instagram Business API access, even in a test context.
The correct test account structure for Instagram Graph API review:
- A Test User created inside Meta App Dashboard under App Roles > Test Users (this is different from a regular Facebook account you create manually)
- A Facebook Page created under the test user's account specifically a Business or Brand Page, not a personal profile
- An Instagram Professional Account (Business or Creator) connected to that Facebook Page via Instagram settings
- The test user must be the Page admin with full admin rights, not just an editor or analyst
- The test Instagram account must have at least 30 days of post history and some engagement data so insights endpoints return real data during review
- The connected Facebook App must be added to the test user's roles inside Meta App Dashboard
This matters because Meta reviewers test using the credentials you provide. If the account structure is wrong, the API calls that depend on Business Account linkage return empty results or errors. The reviewer sees a broken feature and rejects the submission.
Never use a real customer account or a personal account with real data as your review test account. Create a dedicated test account via Meta App Dashboard. This protects your customers and gives you full control over the account's configuration without risking production data.
Third Rejection: Use Case Could Not Be Verified
Third submission. New rejection: 'We were unable to verify that your application's use of the requested permission aligns with our Platform Policies. Please provide a screencast demonstrating the complete user flow.'
We had submitted screenshots. We had written detailed instructions. We had not submitted a video.
Mistake #3: No Screencast Video
Screenshots are not enough. For most Meta permission reviews, a screencast video is effectively mandatory. The Meta reviewer wants to see the flow, not read about it. They want to see the permission dialog appear, see it approved, and see the data appear in your UI. A static screenshot of a dashboard does not prove that the dashboard is powered by the requested API permission.
What a good Meta review screencast must include:
- Start from a fresh browser session not already logged in
- Navigate to your app's entry point and begin the login flow
- Show the Facebook OAuth permission dialog with the requested permissions visible
- Click through every permission screen do not skip or fast-forward
- Complete the login and show the redirect back to your app
- Navigate to the specific feature that uses the requested permission
- Show an actual API call result appearing in the UI not mocked data, real data from the test Instagram account
- Narrate what is happening at each step, or add text callouts so the reviewer understands what they are seeing
- Keep the video under 5 minutes reviewers do not watch long videos in full
- Ensure the video resolution is clear enough to read UI text without zooming
For each permission you are requesting, you need a separate section in the video or a separate video entirely. If you are requesting instagram_manage_insights and instagram_manage_messages, the video must show both features working independently, each triggered by its respective API call.
Record the screencast using the exact test account credentials you are providing to the reviewer. This proves that the account setup is correct and that the feature works end-to-end from their starting point. If something does not work in the recording, it will not work for the reviewer either.
Fourth Rejection: Permissions Not Justified
We submitted a new video, fixed the account structure, improved the instructions. Fourth rejection: 'Some permissions in your request do not appear to be necessary for the features demonstrated. Please revise your permission request to include only permissions required for the described use case.'
We looked at our permission list and saw the problem immediately.
Mistake #4: Requesting Too Many Permissions
When we first built the integration, we had requested every permission we thought we might eventually need. It seemed efficient. We would get everything approved in one submission and build out the features later. This is one of the fastest ways to get rejected.
Our original permission request:
Permissions requested in submission v1:
instagram_basic
instagram_content_publish
instagram_manage_comments
instagram_manage_insights
instagram_manage_messages
pages_show_list
pages_read_engagement
pages_manage_posts
pages_manage_metadata
pages_manage_engagement
business_management
read_insights
Reviewer note: "business_management, pages_manage_metadata, and pages_manage_posts
are not demonstrated in the submitted screencast. Insufficient justification provided."We had included business_management because we thought we might need it for Business Account verification. We had included pages_manage_posts because we were planning a scheduling feature. Neither was built yet. Neither appeared in the video.
The revised permission request we submitted:
Permissions requested in submission v2:
instagram_basic
Required to identify the user's connected Instagram account
instagram_manage_insights
Required to display follower growth, reach, and post performance analytics
instagram_manage_messages
Required to display and respond to Instagram Direct Messages
pages_show_list
Required to present the user's connected Pages for account selection
pages_read_engagement
Required to display Page-level engagement alongside Instagram metrics
Permissions intentionally NOT requested at this time:
instagram_content_publish (planned for Phase 2, will submit separately)
business_management (not required for current feature set)Every permission in the revised list appeared in the video. Every permission had a one-sentence justification tied to a specific UI feature. The list was shorter, but each item was defensible.
Never request permissions for features you have not built yet. Meta reviewers test what you submit. If a permission appears in your request but not in your screencast or instructions, it will trigger a rejection. Plan for multiple submissions as you add features rather than trying to approve everything upfront.
Fifth Rejection: Data Handling Documentation
Fifth submission. We were close. New rejection: 'Your application's data use policy does not clearly describe how Instagram user data collected through this permission will be used, stored, and shared. Please update your privacy policy and data use explanation.'
Mistake #5: Weak Data Handling Documentation
Meta's Platform Policies require you to explicitly document what data you collect for each permission, why you collect it, how long you store it, and who can access it. A generic privacy policy that says 'we collect data to improve our service' does not satisfy this requirement.
What Meta wants for each permission:
- What specific data fields are collected via this permission (e.g., follower count, post IDs, message text)
- The specific purpose for collecting this data (e.g., display analytics to the account owner in the dashboard)
- Data retention period how long is the data stored before deletion (e.g., 90 days of analytics history)
- Who can access the data (e.g., only the authenticated business owner data is not shared with third parties)
- Whether data is transferred to third parties and under what conditions
- User controls how a user can request deletion of their data
We updated our privacy policy to include a dedicated section for each Instagram permission with this information explicitly spelled out. We also updated the 'Data Use' checkboxes in the Meta App Dashboard settings and the 'Data Use' description in the submission form to mirror the privacy policy language exactly. Consistency between these three locations App Dashboard, privacy policy, and submission form is what the reviewer checks.
The Turning Point
After the fifth rejection, we stopped treating the review process as a technical problem and started treating it as a documentation and process problem.
We had not changed a single line of code between submission one and submission five. The integration worked exactly the same way it always had. Every failure was caused by what we gave the reviewer, not by what the application did.
We rebuilt the submission from scratch with a single goal: the reviewer should never need to think. Every action should be spelled out. Every expected result should be described. Every permission should be justified in a single sentence. The video should show exactly what the instructions describe. The test account should be ready for a reviewer who has never heard of our product and has twelve minutes.
What Finally Got Approved
- Facebook Login: approved on submission 4 (separate from Instagram review)
- instagram_basic, pages_show_list, pages_read_engagement: approved on submission 5
- instagram_manage_insights: approved on submission 5
- instagram_manage_messages: approved on submission 6 (separate submission for messaging permissions)
- Meta Webhooks (pages, instagram): approved alongside instagram_manage_messages
Total elapsed time from first submission to final approval: nine weeks. Three of those weeks were our own resubmission preparation time. Six were Meta review queue time. Reviews can take anywhere from 3 business days to 3 weeks depending on queue depth and whether the reviewer needs to escalate to a policy specialist for unusual use cases.
The lesson: build your Meta integration timeline assuming eight to twelve weeks from first submission to full approval, especially if you are requesting Instagram Messaging or advanced Business Manager permissions.
Meta Review Checklist
Business Verification
- Business is verified in Meta Business Manager (required for most advanced permissions)
- Business domain is verified in Meta Business Manager settings
- Business profile is complete: address, phone number, website, and business category
- Business Manager admin email matches the email used for the developer account
- App is linked to the verified Business Manager
Privacy Policy and Terms
- Privacy policy is publicly accessible at a permanent URL (no logins required to view it)
- Privacy policy explicitly lists each Meta permission you are requesting
- Privacy policy describes data collection purpose, retention period, and sharing policies per permission
- Terms of service are publicly accessible
- Data Deletion Instructions URL is configured and functional (required for all apps using Facebook Login)
- Data deletion callback is tested and deletes the correct user data
Review Video
- Video starts from a fresh browser session with no existing login
- Video shows the complete login flow including the OAuth permission dialog
- All requested permissions are visible in the permission dialog during the recording
- Video demonstrates every permission individually each permission has a corresponding UI feature shown
- API response data is visible in the UI (not mocked or placeholder data)
- Video is under 5 minutes per permission
- Video resolution is high enough to read UI text clearly
- Video is in MP4 format under 100MB, or hosted at an accessible URL (YouTube, Loom, Vimeo)
- Audio narration or text callouts explain each step for a reviewer unfamiliar with the product
Test Accounts
- Test User created inside Meta App Dashboard under Roles > Test Users (not a manually created Facebook account)
- Test User has accepted the app role invitation
- Test Facebook Page created under the test user a Business or Brand Page, not a personal profile
- Test Instagram Professional Account (Business or Creator) connected to the test Facebook Page
- Test user is Page admin with full admin rights
- Test Instagram account has 30+ days of post history with real engagement data
- Test credentials included in submission instructions and confirmed to work before submission
- Test account can reproduce every step in the submitted instructions
Permissions
- Only permissions actively used in the current feature set are requested
- Each permission has a one-sentence justification in the submission form
- Each permission is demonstrated in the review video
- No permissions are requested 'for future use' submit a new review when those features are built
- Data use checkboxes in App Dashboard settings match the privacy policy language
- Permission justifications are specific to the use case (not generic boilerplate)
Review Instructions
- Instructions include exact URLs, button names, and expected results at every step
- Test account credentials are prominently displayed at the top of the instructions
- Instructions are written assuming zero prior knowledge of the product
- Instructions account for all redirects, loading states, and intermediate screens
- Expected results describe exactly what the reviewer should see (numbers, labels, UI elements)
- Instructions note any known delays (e.g., 'data may take up to 10 seconds to load')
Webhook Testing
- Webhook endpoint is publicly accessible and responds to Meta's verification GET request
- Webhook verification token matches the token configured in App Dashboard
- Webhook endpoint responds with HTTP 200 to all test events within 3 seconds
- Webhook endpoint URL is in production (not localhost or a development tunnel)
- Webhook event subscriptions are configured for the correct objects and fields
- Webhook signature verification is implemented and tested
Facebook Login Review Checklist
Facebook Login review is the entry point for most Meta integrations. It is typically the fastest review to pass, but common mistakes still cause rejections.
- Valid OAuth redirect URIs are configured in App Dashboard (exact match, including trailing slash)
- Login flow requests only the permissions needed at login (email and public_profile for most apps)
- Deauthorize Callback URL is configured and tested Meta sends a signed request when a user removes the app
- Data Deletion Request URL is configured and returns a confirmation code
- Login button is clearly visible and labeled correctly ('Continue with Facebook' per Meta branding guidelines)
- App does not force users to connect Facebook when a non-Facebook login option exists
- Privacy policy link is displayed near the login button
- Test shows the full login-to-redirect flow including the permission dialog
- App handles declined permissions gracefully does not crash if user denies optional permissions
A common Facebook Login rejection: the app requests email permission but the reviewer cannot see how the email is used in the product. Either show the email being used (e.g., displayed in account settings or used for notifications) or do not request it at login. 'We might use it later' is not an accepted justification.
Instagram Graph API Review Checklist
Instagram Graph API reviews are the most thorough in the Meta ecosystem. Every permission requires an individual justification, a separate video demonstration, and a test Instagram Professional Account with real data.
- App is linked to a verified Business Manager
- Test Instagram account is a Professional Account (Business or Creator) personal accounts cannot be used
- Test Instagram account is connected to a Facebook Page that the test user admins
- instagram_basic is requested alongside any other Instagram permission (it is required as a foundation)
- Each Instagram permission has a separate section in the instructions and a corresponding segment in the video
- instagram_manage_insights: video shows actual analytics data rendered in the UI from the API response
- instagram_content_publish: video shows a post being created and published to the test Instagram account
- instagram_manage_comments: video shows comments being read and a reply being sent
- instagram_manage_messages: video shows a DM conversation appearing in the app UI
- API responses visible in the video contain real data from the test account (not placeholder text)
- Privacy policy covers Instagram data specifically, not just generic API data
WhatsApp Business API Review Checklist
WhatsApp Business API approval has additional requirements beyond standard Meta permissions. Business verification must be complete before WhatsApp API access is granted.
- Business is verified in Meta Business Manager with legal business name and address
- WhatsApp Business Account is created and linked to the verified Business Manager
- Display name is submitted for approval must match the business name or be a recognized brand variant
- Display name approval is complete before submitting messaging permission requests
- Phone number is registered and verified for WhatsApp Business API use
- Message templates are created and approved before testing template-based messaging flows
- Privacy policy explicitly covers WhatsApp message data: what messages are stored, for how long, and who can access them
- Opt-in flow is implemented: users must explicitly consent to receive WhatsApp messages before the first message is sent
- Opt-in consent is documented in the submission and shown in the review video
- App does not send template messages to users who have not opted in
- Business use case does not violate WhatsApp's Commerce Policy (no alcohol, gambling, or financial services in restricted markets)
Lessons Learned
- 1Meta reviewers are not your users and they are not your QA team they have a fixed time budget per submission and will not investigate beyond your instructions
- 2Every rejection that says 'could not reproduce' means the instructions were incomplete, not that the feature is broken
- 3A screencast video is not optional for Instagram Graph API permissions treat it as required and invest the time to make it good
- 4Record the video using the exact test credentials you are providing to the reviewer so you know the account setup is correct before submission
- 5Create test accounts via Meta App Dashboard's Roles > Test Users feature not a manually created personal account
- 6The test Instagram account must be a Professional Account connected to a Facebook Page and have real post history
- 7Request only permissions for features you have built and demonstrated never request speculative future permissions
- 8Each permission needs a one-sentence justification tied to a specific UI feature, not a generic explanation
- 9Your privacy policy must explicitly cover each Meta permission with data type, purpose, retention, and access details
- 10Data use descriptions in App Dashboard, the privacy policy, and the submission form should use consistent language
- 11Plan for two to three rounds of review per permission category as a baseline budget eight to twelve weeks for full approval
- 12Facebook Login review is separate from Instagram Graph API review, which is separate from Instagram Messaging review each has its own timeline
- 13If a rejection reason is vague, do not guess at the root cause check every item on the checklist before resubmitting
- 14The Meta Developer Support portal allows you to ask for clarification on a rejection before resubmitting this can save a full review cycle
- 15App review is not the final step before launch it is a process that continues every time you add new permissions or change your use case
What Nurture Technologies Recommends
After going through this process ourselves, we built a framework we use for every Meta integration submission. The seven stages:
flowchart TD
A["Verify\nBusiness + domain in\nMeta Business Manager"] --> B["Document\nPrivacy policy + terms\nData use per permission"]
B --> C["Record\nScreencast video for\neach permission"]
C --> D["Test\nTest accounts + full\nflow dry run"]
D --> E["Submit\nReview request with\ninstructions + video"]
E --> F["Review\nInternal checklist audit\nbefore submission"]
F --> G["Approve\n✓ Permission granted"]
G --> H["Expand\nAdd next permission\nin separate submission"]- Verify: complete business verification and domain verification in Meta Business Manager before writing a line of review documentation
- Document: write the privacy policy, terms of service, and data use descriptions covering every permission you will request
- Record: make the screencast using the exact test account you will provide; confirm every step works as shown
- Test: have someone who has never used the product follow your written instructions and complete the flow using only what you have written
- Submit: fill every required field in the review form; do not leave optional fields blank if they are relevant
- Review: run through the internal checklist before clicking submit every item checked is one less rejection reason
- Expand: once approved, add new permissions in separate submissions rather than bundling everything into one
Conclusion
Most Meta app review failures are not caused by code. The integration works. The API calls succeed. The feature is built correctly.
They are caused by poor documentation, incomplete instructions, wrong test account structures, over-broad permission requests, and review videos that do not show what reviewers need to see. The reviewer cannot approve what they cannot verify. If your submission does not give them everything they need to verify the feature independently, they will reject it.
The fix is systematic. Run through the full checklist before every submission. Write the instructions for someone who has never heard of your product. Record the video starting from a fresh session with the exact test credentials you are providing. Request only the permissions for features you have built. Document your data use specifically and completely.
Do that, and Meta app review becomes a process you can manage rather than a lottery you keep losing.
Need help implementing a Meta integration, navigating the app review process, or building production-ready Instagram, Facebook, or WhatsApp Business API workflows? Nurture Technologies helps businesses design, implement, secure, and successfully launch Meta integrations from initial architecture and OAuth implementation through app review preparation, business verification, and production deployment. Talk to us about your Meta integration.