You're right. It isn't.

We spent three months building the Meta integration for MarketPilot AI, a platform that helps digital marketers plan, publish, and measure campaigns from one place. The engineering was the easy part. The hard part was proving to a stranger, in a video, that we deserved access to other people's data.

This guide is what we wish had existed when we started. It's long because App Review is long. Read it once end to end, then keep it open in a tab while you work. Everything here is ordered the way you should actually do it.

What you'll find inside: the vocabulary, a five-week build order, the Instagram Login vs Facebook Login decision that trips up half of all applicants, a copy-paste submission notes template, a shot-by-shot screencast script, a rejection-to-fix lookup table, and the post-approval obligations nobody warns you about.

The one mental model that changes everything

Before any of the mechanics, internalise this:

"You are not being tested . You are being understood, by a person under time pressure, using only the video you gave them."

Reviews work through a queue. They are not going to explore your product, guess at your architecture, or give you the benefit of the doubt. They open your submission, read your notes, watch your screencast, and decide whether they can see each requested permission being used for the reason you claimed.

Three consequences fall out of this, and they explain almost every rejection ever issued:

1. If it isn't in the video, it doesn't exist. Your beautiful feature, your clever architecture, your enterprise clients: invisible. The video is the entire submission.

2. Ambiguity reads as risk. A reviewer who isn't sure what they're looking at will reject .It costs them nothing to reject. It costs them a lot to wrongly approve.

3. Each permission is judged separately. You can be approved for six scopes and denied two in the same submission, with different reasons for each. Your product isn't approved or rejected. Your permissions are.

Everything below is in service of making a tired person's job easy.

The vocabulary, in plain English
You cannot navigate the dashboard until these five words mean something concrete to you.

And two modes:

• Development mode - your app works fully, but only for admins, developers and testers.

• Live mode - your app works for the public, but only for permissions granted Advanced Access.

The trap most people fall into: they build the whole product in Development mode where everything works beautifully, then flip to Live and watch it collapse, because Standard Access silently returns empty arrays instead of errors. Empty data: [] is not a bug. It's Meta telling you that you don't have Advanced Access yet.

Why MarketPilot needed this at all
Our integrations section connects a marketer's Facebook Pages, Instagram business account, an ad account, then pulls performance data into one dashboard and pushes scheduled content back out. Every single one of those actions touches data belonging to someone who is not us. There is no version of that product that works on Standard Access. App Review
wasn't a compliance checkbox for us. It was the gate between a demo and
a business.
If your product does anything on behalf of a client, you're in the same position. Plan for it as a workstream not a form.

The build order (roughly five weeks)
Do these in sequence. The single most expensive mistake in App Review is doing things in the wrong order and discovering a blocker after a two-week wait.

Week 1: Business Verification and app Hygiene
Start Business Verification on day one: It runs in a completely separate queue from App Review, it gates Advanced Access on the more sensitive permissions, and it's the one thing you cannot rush at the end.

You'll need documents where the business name and address match exactly across all of the. Typically a certificate of incorporation or business registration, plus a proof of address such as a utility bill or bank statement. A mismatch between "MarketPilot Ltd" and "MarketPilot Limited" on two documents in enough to fail. Check before uploading.

You'll also be asked to classify your business. If your app provides services to other businesses who use it to manage their own Meta assets(which is what MarketPilot does, and probably what you do), you're a Tech Provider. Getting this wrong changes the permissions you're eligible for, so read the definitions carefully rather than guessing.

While verification is in the queue, fix your app settings. Reviewers click every one of these:

• Privacy Policy URL - same

• Terms of Service URL - same

• App Icon(1024x1024) and a real category

• Data Deletion Request Callback - a live endpoint, not a placeholder

• Deauthorize callback - fires when a user removes your app

• Valid OAuth redirects URIs and your app domains

A 404 on any of these can sink an otherwise flawless submission. This is the cheapest possible thing to get right, and it fails people instantly.
For your engineer: the two callbacks are POST endpoints receiving a signed request from Meta. Verify the signature with your app secret, then delete
or queue deletion of that user's data. The deletion endpoint must return a JSON body containing a confirmation URL and code that a user could check

Week 2: Pick your login architecture
This is the fork in the road, and choosing wrong means rebuilding your auth flow after a rejection.
If you're touching Instagram, there are two entirely different ways to connect, with different permissions, different capabilities, and different review expectations.

Choose based on your product, not on which tutorial you found first. If, like us, you need Pages, Instagram, and ads in a single connect flow, Facebook Login us the right answer and the extra permission surface is worth it. If you only publish to Instagram, Instagram Login gets your users through onboarding with far less friction.

Then design your token flow, because this is where production breaks.

1. The login returns a short-lived user token(about an hour).

2. Exchange it server-side for a long-lived user token(roughly 60 days).

3. Use that to fetch Page access tokens, which don't expire on their own as long as the underlying long-lived token stays valid and the user doesn't revoke or change their password.

4. Store tokens encrypted. Build a refresh job. Build a graceful "please reconnect" state in your UI.

Nothing about token expiry is part of App Review, but a reviewer clicking around a broken integration because your token died overnight absolutely is.

Week 3: Build, and generate real API calls

Now open Use Cases in the dashboard. You'll see a catalogue: Create & manage ads with Marketing API, Measure ad performance data, Manage messaging & content on Instagram, Manage everything on your Page, Access the Threads API, Connect with customers through WhatsApp, Manage products with Catalog API, and more.

Pick the ones that describe your product and hit Customize. That screen is where the real work lives.

The Permissions and features table has four columns that matter:
The permission, with Full Description and Requirements links beneath it. The Requirements link tells you, per permission, exactly what your screencast must demonstrate. Read every single one before you plan your recording. A shocking share of rejections are just people who never opened this.

API Calls. Meta counts how many times your app has actually hit the endpoints behind that permission. A scope showing a dash is a scope you haven't proven you use. You need real, logged calls before you submit. This is not optional and it catches people by surprise the day they try to submit.

Status. Scopes you hold show Ready to publish. Everything else shows a dash.
Action. Either a dropdown for permissions you already have, or an Add to App Review button for ones you want. That button is how a permission enters your submission.

Request only what you use. Every extra permission is another thing you must demonstrate on camera and another chance to be denied. Nine well-demonstrated scopes beat twelve half-shown ones, and a denial on any one of them costs you two weeks.

Week 4: Testers, and a working demo
Under App Roles, add Administrators, Developers and Testers.

This is the most underused feature in the entire dashboard. Anyone with a role on your app can grant your app unapproved permissions on their own account. That means a fully working integration, with real data, before Meta has approved anything.

Use it to:

• Give engineers real Pages and real ad accounts to build against.

• Let a friendly design partner trial the integration early and tell you what's confusing.

• Record a screencast in which every button genuinely works.

The catch: testers must accept the invite from their own Facebook settings under Apps and Websites. Half of all "it's not working" bug reports are an unaccepted invite.

Meanwhile, the Testing section creates a test app (a clone with its own App ID)and test users with synthetic Pages and data. Use it for experiments you don't want anywhere near production config. Do not record your final screencast on a test app, though. Reviewers want your real product at your real domain

Week 5: Record, write, submit
That's the next two sections.

The submission notes
Your written notes are the second thing the reviewer reads, right after your app name. Most people write two vague sentences here. Don't. The notes are where you tell the reviewer what they're about to see, so that when they see it, they recognise it.

APP OVERVIEW MarketPilot AI is a marketing platform for agencies and in-house marketing teams. Users connect the Facebook Pages, Instagram business accounts, and ad accounts they manage, and MarketPilot shows unified performance reporting and schedules content across those channels.

TEST CREDENTIALS URL: https://app.marketpilot.io Email: reviewer@marketpilot.io Password: [password] These credentials were verified working on [date].

HOW TO REPRODUCE (also shown in the screencast)

1. Go to https://app.marketpilot.io and sign in with the credentials above.

2. Click "Integrations" in the left sidebar.

3. Click "Connect Facebook". The Meta login dialog opens.

4. Grant access to the Page "MarketPilot Demo" and the linked Instagram business account.

5. You land on the Integrations page showing the connected assets.

6. Click "Analytics" to see Page and Instagram performance data.

7. Click "Content > Schedule" to publish a post.

PERMISSIONS

pages_show_list Why we need it: to display the list of Pages a user manages so they can choose which ones MarketPilot should work with. Where it appears in the app: the Page selector on the Integrations page. In the screencast: 00:42 - 00:58.

pages_read_engagement Why we need it: to read post and engagement data for the connected Page so we can show which content performed best. Where it appears: the Analytics dashboard, "Top Posts" module. In the screencast: 01:20 - 01:55.

instagram_manage_insights Why we need it: to retrieve reach and engagement metrics for the connected Instagram business account and display them alongside Facebook data in one report. Where it appears: the Analytics dashboard, Instagram tab. In the screencast: 02:10 - 02:48.

ARCHITECTURE NOTE [Include only if true] Parts of our data sync run server-to-server using a system user token, so no front-end login flow is visible for those calls. The user-facing login and consent flow is shown in full at the start of the screencast.

Three things this template does that a paragraph cannot:

• Timestamps turn your video into a document the reviewer can navigate. This alone speeds up approvals.

• "Where it appears in the app" answers the exact question the reviewer is asking.

• The architecture note pre-empts the "we could not see the login flow" rejection, which is otherwise almost impossible to escape for backend-heavy apps.

The screencast: a director's guide
This is the whole ballgame. Budget half a day for it and treat it like production, not a screen grab.

Pre-production checklist

• Test credentials verified in an incognito window, on a second device, that morning

• Two-factor authentication turned off on the demo account, or the reviewer cannot log in

• Demo Page and Instagram account populated with real-looking content: posts, comments, some engagement history. Empty dashboards read as a fake product.

• Every integration working end to end when logged in as the test user

• App interface language set to English

• Browser cleaned up: no personal bookmarks, no unrelated tabs, no notifications

• Recording at 1280×720 or better, in a maximised window

• Cursor visible and moving deliberately

The script
Record one continuous take per use case. Narrate out loud, or add clear captions if you'd rather not speak. Its not a necessity either. You can as well record only.
-Show the browser address bar with your real domain. Not localhost. Not a staging subdomain that looks like a test. Then log in on camera with the exact credentials you gave Meta.
-Don't teleport via a deep link. Show the navigation. The reviewer needs to believe a real customer could find this feature.
-Show the login dialog, scroll the permission screen so the scopes are readable on camera, show the Page and asset selector, show the click that grants consent. Do not cut anywhere in this section. A jump cut around consent looks like something is being hidden, and it will be read that way.

Prove every single permission

This is where approvals are won. For each scope you requested, show the result on screen. If you're narrating, say the permission's name out loud as you show it. If you're not, put it on screen as a caption.

Loading spinners don't count. Empty states don't count. Placeholder data does not count and is actively suspicious. Real data on screen, tied to the account you just connected counts,

Closing - the disconnect flow

"Finally, a user can remove the connection at any time. I click Disconnect, confirm, and MarketPilot no longer has access. The data is removed from the dashboard."

Almost nobody records this. It takes fifteen seconds and it tells the reviewer you treat consent as reversible. It is one of the highest-return shots in the whole video.

The twelve things that get screencasts rejected

1. The permission was never actually shown being used.

2. The login flow was cut, sped up, or skipped.

3. Test credentials didn't work, or 2FA blocked the reviewer.

4. The app interface was not in English.

5. No narration and no captions, leaving the reviewer to guess.(Not necessary)

6. Recorded on localhost or an obvious prototype

7. A phone camera pointed at a monitor, or a slideshow instead of a screenrecording

8. Empty dashboards with no real data

9. The video shows a different flow than the written instructions described.

10. Only some of the requested permissions were demonstrated

11. Server-to-server architecture not disclosed , so the missing login flow looked like an omission.

12. Privacy policy, terms, or data deletion URLs returning errors when clicked

Upload the video file directly to the submission where you can. A reviewer who hits a permission wall on your video link will reject rather than email you.

How to read a rejection
Here is the thing nobody tells first-timers, and it's genuinely good news:

Meta tells you the specific reason for every individual rejected scope.

Open your App Review submission feedback and you'll see each denied permission listed by name, on it's own card, containing a short reason title. the developer policy it falls under, a numbered list of exactly what your next screencast must contain , links to the screen recording guide and the common rejection guidelines, and a Request again button.

That numbered list is a grading rubric handed to you after the exam. In our case, nearly every rejection reduced to the same four asks: show the complete login flow, show the user granting access, show the end-to-end experience of the use case, and follow the recording best practices around English UI.

So when denial lands, resist the urge to rewrite everything. Find the one specific thing they couldn't see, fix that and resubmit.

Rejection -> root cause -> fix

Resubmission Strategy

• Submit all permissions for a use case together. Sequential submissions mean sequential two-week waits.

• Expect 10 to 14 business days for a decision. Some come back in three days. Some sit for two weeks and change. Business Verification runs on its own clock entirely.

• Keep building during the wait. Testers give you a working integration, so nothing needs to be blocked.

• Don't spam re-submissions. Repeated low-effort attempts slow your queue position and win you no goodwill.

• Change something real between attempts. Resubmitting the same video with a longer paragraph is how people lose two months.

Ours took multiple rounds. A lot of back and forth. Re-recording the same flow at 1am because a reviewer couldn't clearly see the Page selector. It is tedious, and then one morning the email says Approved and you forget it all.

What happens after approval

Approval is a beginning, not an ending. Three things will surprise you.
Advanced Access can be revoked. If your app violates platform terms,sits unused for a long period, or fails a later assessment, permissions can be pulled. Approval is a licence, not a deed.

You will likely face a Data Protection Assessment. Apps with advanced access to certain data are periodically required to complete a detailed questionnaire about how they store , share, and protect user data, including your security practices and any third parties you send data to. It arrives with a deadline, and missing the deadline costs you your access. Answer it seriously, with your actual engineering practices in hand.

Rate limits become your new problem. Platform limits scale with your user count, and the Marketing API applies its own business use case limits per ad account. Build caching, batching, and exponential backoff before your first big customer, not after they complain that reports are empty.

Also plan for the mundane: tokens expiring, users changing passwords, clients removing your app, and Meta deprecating API versions on a rolling schedule. Every one of these looks identical to your customer, who sees only "my data is gone." Build a clear reconnect flow and a status indicator on your integrations page. Your support inbox will thank you.

The last thing
Meta App Review isn't a measure of your engineering. It's a measure of how clearly you can show a stranger, in one unbroken take, that you're using someone's data for exactly the reason you said you would.
Build the feature properly. Then film it honestly. Everything else is Admin.

We're building MarketPilot AI for digital marketers who are tired of stitching six tools together. If you're stuck in App Review right now, drop your rejection reason in the comments and I'll tell you what we did about the exact one.
API versions, permission names, and dashboard layouts change. Verify anything version-specific against Meta's current documentation before you build it.

Google.
And this time, I couldn't simply write code and move on. I had to explain what my application does, what Google data it needs, and why it needs that data, demonstrate the functionality, record a video, submit everything for review - and then wait. The article is about that process.

Why do you need Google APIs?
If you're new to Google Cloud, the words Google APIs, OAuth, scopes and verification can sound unnecessarily complicated. They become much easier when you think about them this way:

"Your application wants to talk to Google's services on behalf of a user. Google wants to know exactly what your application is going to do."

For MarketPilot, integrations such as Google Ads, Google Analytics 4, YouTube and Google Tag Manager, Google Merchant Center aren't just nice-to-have features. They allow MarketPilot to connect marketing activity with the rest of customer's digital ecosystem.
For example:

YouTube API - allows the application to work with a user's YouTube account and related resources.
Google Ads API - allows the application to work with advertising accounts and campaign data
Google Analytics 4 API - allows the application to retrieve analytics data so marketing performance can be understood.
Google Tag Manager API - allows the application to interact with tag management resources.

The exact permissions depend on what your application actually needs. And the last sentence is important . ASK FOR THE MINIMUM PERMISSIONS YOU NEED. Don't request every scope simply because it is available. Google explicitly recommends using less sensitive scopes where possible and sensitive scopes can require additional review

STEP 1: CREATE A GOOGLE CLOUD PROJECT
First, go to Google Cloud Console and create a new project for your application. Give it a name that clearly identifies your app, such as MarketPilot AI. This project will be where you manage your APIs, OAuth settings, credentials and other Google Cloud services. Once your project exists, you'll spend a lot of time inside APIs & Services

STEP 2: FIND APIs YOU NEED
Once your project is created , go to APIs & Services -> Library. Search for the Google APIs your application needs, such as YouTube, Google Ads, Google Analytics, or Google Tag Manager. Open each API and click Enable. Before enabling anything, write down: "What feature in my application requires this API?" Only enable the APIs your application actually uses. That simple exercise makes the next step - OAuth scopes - much easier.

STEP 3: CONFIGURE OAUTH
Next, go to your OAuth configuration under Google Auth Platform/ OAuth consent configuration. This is where you tell Google about your application - it's name, logo, website, contact details, and how users will sign in and give permission to your app**.** Think of the OAuth consent screen as the conversation between your application and the user:

"MarketPilot wants access to X because it needs it to do Y"

The user should understand what they're granting.

STEP 4: BE VERY CAREFUL WITH SCOPES
Scopes define what your application is allowed to access. Add only the scopes your application genuinely needs. For example, if MarketPilot needs to read a user's analytics data, request the appropriate Analytics scope. Avoid adding extra permissions just because they are available. The temptation is to add every scope you think you might need someday,Don't. Instead, go through your application feature by feature.

A useful rule
Feature = Required Google data = Required Scope

Not:

Google API = Every Scope available
That distinction can save you a lot of trouble later.

STEP 5: REMOVE SCOPES YOU DON'T NEED
This sounds obvious, but it's surprisingly easy to forget. During development, you may experiment with different APIs and permissions. Eventually, you should clean them up.
If a scope is no longer required, remove it from your configured data access and remove it from your application'S OAuth requests.
Google specifically warns that removing a scope from the console but continuing to request it in your application can cause problems, including an unverified-app warning.
Before submitting your application, I recommend creating a simple checklist:
-API enabled
-OAuth client configured
-Required scopes added
-Unnecessary scopes removed
-Application requests exactly those scopes
-Privacy Policy available
-Terms/details completed where required
-Application is working in production
-Demo account/test flow prepared

STEP 6: EXPLAIN WHY YOU NEED EACH SCOPE
For each sensitive scope, explain why your application needs it and how it will be used. Keep the explanation simple and specific. Tell the reviewer what the user does, what data is accessed, and what your application does with that data. Explain the user journey. The reviewer should be able to answer three questions immediately:
What data are you accessing?
Why do you need it?
Where is it used in the applications?

For example:
"A MarketPilot user connects their Google Analytics property so the application can retrieve performance and metrics and display them alongside their marketing activity. The data is used to generate performance reports and recommendations inside the user's MarketPilot workspace,"

STEP 7: RECORD THE DEMO VIDEO
This was probably the part I paid the most attention to.
Google doesn't just want a marketing video. They want to see the actual application and OAuth flow. Your demo should show the end-to-end experience. Google's current guidance says the video should demonstrate the OAuth grant process, the complete consent scree, the requested scopes, and the functionality that uses those scopes.
For MarketPilot, I approached the video almost like a product walk-through for a reviewer.

My demo flow
On an incognito tab
1. Show MarketPilot
Start with the actual application
Show the application name and branding.

2. Show the feature requiring Google Access
Don't make the reviewer guess why you're asking for permission
Show the actual feature.

3. Start the connection process
Click the Google connection button

4. Show the OAuth consent screen
Let the reviewer see what permissions are being requested.

5. Authorize the application
Complete the OAuth flow

6. Return to MarketPilot
Show that Google account is now connected

7. Demonstrate the functionality
This is critical. Don't stop after authentication. Show what your application actually does with that authorized data.

For example:
Connect Google Analytics -> Retrieve data -> Display it in MarketPilot ->
Use that data in reporting

That closes the loop.

STEP 8: UPLOAD THE DEMO
Google's current guidance for verification asks for a demonstration video, and for restricted-scope verification the documentation specifically recommends uploading the video to YouTube with visibility set to Unlisted.

In case you fail any of the scopes in the screencast, the Google verification team will respond to you via email with instructions on what you need to do next. You can simply follow the steps they provide.
Since the video I initially uploaded to YouTube kept getting removed, I decided to host it on Google Drive instead. I set the sharing permissions to "Anyone with the link - Viewer" and then shared the Google Drive link via email

I kept the video focused.
No dramatic intro.
No 10-minute explanation of the startup.
No background music.
The reviewer doesn't need commercial.
They need evidence.

Show the product. Show the OAuth flow. Show the scopes. Show how the permissions are actually used.
If you use multiple OAuth clients or multiple OAuth workflows, Google expects the relevant flows to be demonstrated as well.

STEP 9: SUBMIT THE APPLICATION
Once everything is ready, the final stage is submission.
Google's current process requires the application to be published to production before preparing it for verification. You then review the configured information, provide scope justification, provide the demo video, and submit the verification request.

Useful Google Documentation
If you're going through this process yourself, these are the pages I would bookmark:
Google Cloud - Getting Started with Cloud APIs
Google - OAuth 2.0 Scopes
Google Cloud - Submitting Your App for Verification
Google Cloud - Demo Video Requirements

If you're building something that needs Google APIs and you're currently staring at the Cloud Console wondering where to start - I hope this saves you some time.