Meta App Review, Start to Finish: Every Gate Between You and Advanced Access

We went into Meta App Review expecting one submission: record some screencasts, describe the permissions, press submit. What we found was a chain of gates, each with its own form, its own review clock, and its own way of rejecting you. This guide maps the whole chain, in the order it unlocks, with the timings we measured filing it for Savra this week.

The short version: for an app that reads data belonging to other businesses, the sequence is business verification, then access verification as a Tech Provider, then the submission itself, which is five sections deep. Companion guides cover business verification and access verification trap by trap; this post is the map that shows where they fit.

What does the full chain look like?

The dependency is strict. Access verification sat locked on our dashboard with a message that business verification had to finish first, and the submission wizard's own checklist puts verification at the top. Start the chain the moment App Review lands on your roadmap, because nothing downstream moves until the first gate clears.

The submission wizard itself has five sections: Verification (inherited from the two gates above), App settings, Allowed usage, Data handling, and Reviewer instructions. All five need green checks before the submit button means anything.

What does App settings actually check?

The mundane fields, and they can silently make you ineligible. Our dashboard showed "Currently ineligible for submission" over a single missing field: the app category. While fixing it we found two placeholder URLs a reviewer would have caught: the Terms of Service field and the data-deletion field both still pointed at facebook.com from some early setup day. Both now point at our real terms and our privacy policy, which documents deletion.

Sweep this page before anything else: display name, category, icon, privacy policy URL, terms URL, data deletion URL, a contact email on your product's domain, and at least one registered platform. The reviewer-instructions section refuses to open until a platform exists, which for a web app means adding Website with your app's URL.

What is Allowed usage?

One card per requested permission, and each card wants four things: a written description of how the app uses the permission, a screencast of the feature end to end, evidence of API test calls within the last 30 days, and a checkbox agreeing to the allowed usage.

Two rejection traps live here. Meta names copied descriptions between permissions as a rejection cause, so every description must be written separately: what the permission does for the user, why the app needs it, and what breaks without it. And the test-call requirement means a permission your code never exercises cannot be submitted at all, its card simply never completes. That constraint did our pruning for us: our draft had accumulated around 27 permissions from setup wizards, and the product exercises 8. We removed the rest. Fewer permissions also means fewer screencasts, and the screencast specs are strict: 1080p or better, recorded at a window width of 1440 or less, cursor visible, English interface, no audio, one recording per permission.

What are the Data Handling Questions?

A questionnaire about your data chain: which outside companies can access the Platform Data you obtain from Meta and in which countries, which legal entity is the data controller, and how you handle public-authority requests for user data.

Prepare the answers on paper first, for two reasons. Three insufficient answers in a row lock the questionnaire for three days. And the answers are checkable claims, so each one should come from your code rather than your architecture diagram. Building our processor list meant tracing where Platform Data actually flows, which removed one vendor from the draft and triggered a data-processing agreement we cover in a companion post.

What do Reviewer instructions require?

A human reviewer logs into your app and clicks through every feature, and Meta is blunt about the stakes: a reviewer who cannot access the app rejects the whole submission. If your app has real sign-up gates, and any production app with billing does, you supply a working test login in the instructions.

That login has to open onto a live account, which is where preparation gets physical. Ours belongs to our own business's workspace, with our Facebook Page and Instagram account already connected and published posts carrying real engagement, so the reviewer sees every permission doing its job on real data the moment they sign in. The instructions spell out the exact click path to each feature, because reviewers follow paths rather than explore. Two details worth copying: confirm in the instructions how your app uses Facebook Login, since the form asks for that explicitly, and keep the credentials alive well past submission, because Meta asks for a year and a second review round will reuse them.

What throttles the process?

Three limits shape strategy. One submission can be open at a time, so permissions you cannot yet demonstrate belong in a later round rather than in the current one. Five rejections inside seven days restricts the app, which is why we excluded unused permissions instead of gambling on them. And logged API calls expire out of the 30-day window, so time your submission while the evidence is fresh.

Our own status as this publishes: both verification gates cleared, questionnaire filed, all eight descriptions in, screencasts in production. The post about what reviewers actually checked gets written when the decision exists.

FAQ

What are the stages for a business app?
Business verification, access verification as a Tech Provider, then the submission: app settings, allowed usage with screencasts, Data Handling Questions, reviewer instructions. Each stays locked until the previous clears.

How long does each stage take?
Quotes: two business days, five days, then several business days per review round. Our two verification gates cleared overnight and same-day, so the quotes are ceilings.

Which permissions should you include?
Only what your code exercises. Each permission needs logged calls within 30 days, a unique description, and its own screencast, so unused permissions cannot complete anyway.

What rejects a submission fastest?
A test account the reviewer cannot use rejects everything. Copied usage descriptions are a named rejection cause. Placeholder URLs in app settings and missing screencast grants follow close behind.