Real Client Case Study
An ads analytics and attribution SaaS platform — the kind of tool marketing teams use to pull ad performance data into custom dashboards — needed three Meta permissions approved: business_management, ads_read, and ads_management. The client had already tried twice on their own and been rejected both times, for the same reason both times. They hired us specifically because they didn’t want to burn a third attempt guessing at what Meta actually wanted to see.
The Permissions Requested
Marketing API Access Tier
To unlock ad account management and higher rate limits, the app needed the Marketing API Access Tier, which requires at least one of the two ads scopes below to be approved:
ads_read
Read-only access to ad performance data and Ads Insights for accounts the user owns or has been granted access to
ads_management
Read and manage ads for accounts the user owns or has been granted access to
business_management
Access Business Manager data — ad accounts, assets, and system users
public_profile
Base login permission, auto-granted, renewed alongside every submission
Two Rejections, Same Reason
The client’s team had submitted this exact permission set twice before we got involved — once in early May, once later that month. Both times, the outcome was almost identical:
Submission 1 — Not Approved
business_management, ads_read, ads_management, pages_show_list, and pages_read_engagement were all rejected. Only public_profile came back approved.
Submission 2 — Not Approved (same scopes, same result)
A resubmission of the same permission set, three weeks later, was rejected again with an identical pattern — every ads and business scope declined, only public_profile renewed. Nothing in the submission had meaningfully changed between rounds.
The Real Problem Wasn’t the Permissions — It Was the Demo
Meta doesn’t just read your use-case description. For ads_read and similar scopes, reviewers require a screen recording that shows the permission actually working end-to-end inside the app. Reusing an account that was already connected from a prior test, or recording a flow where the ad account was imported before recording started, doesn’t show a reviewer anything — there’s no visible proof the app’s own connection flow produces real, permission-gated data.
The Fix — Rebuilding the Screen Recording From a Clean State
Before recording a new screencast, the app first had to be removed from the test account’s connected apps in Facebook’s Business Integrations settings. Recording over an already-connected account hides the exact step Meta needs to see. Once the connection was reset, the correct recording sequence was:
Step 1 — Start From Zero
Remove the app from Facebook’s connected Business Tools before recording begins, so the OAuth connection isn’t pre-established.
Step 2 — Record the Real Connection Flow
Begin recording, log into the SaaS dashboard, and trigger the actual “Connect Facebook” flow — not a shortcut, not a pre-authorized session.
Step 3 — Import a Live Ad Account
Complete the Facebook OAuth prompt and import a real ad account through the app’s own import flow, on camera.
Step 4 — Show the Permission in Use
Display the imported ad account’s ads with live insights data rendering inside the SaaS dashboard — the concrete proof that ads_read is doing what the use-case description says it does.
This sequence was documented step-by-step and handed to the client’s team, since their developer — not us — had direct access to a live ad account to record from.
Result
ads_read — Approved
Marketing API Access Tier — Renewed
public_profile — Renewed
business_management and ads_management were intentionally left out of this submission. After two failed attempts bundling every scope together, the safer path was to get one critical permission through cleanly first, on a corrected recording, rather than risk a third blanket rejection. Those two scopes are the client’s next round.
Hired May 30 → approved July 1, 2026
Key Lessons From This Project
An already-connected test account produces a worthless demo. If the app was authorized before the camera started rolling, the reviewer never sees the actual permission-gated connection happen — that’s an instant, repeatable rejection.
Identical resubmissions get identical results. Submitting the exact same permission set and video a second time, without fixing the underlying demo problem, wastes another review cycle — Meta’s reviewers are evaluating the evidence, not the intent.
Bundling too many scopes raises the risk of a blanket “not approved.” After two failed attempts on the full set, scoping the resubmission down to the single most important permission (ads_read) got a clean approval instead of another all-or-nothing rejection.
Whoever has the live ad account has to do the recording. We couldn’t record a realistic ads_read demo from an account with no ad spend or campaigns — the client’s own developer, with access to a live ad account, had to record it following an exact step-by-step sequence we provided.
If your app needs ads_read or ads_management approved, our Facebook Ads API permission guide covers what reviewers check for each scope, and the Meta Ads API approval overview explains how the Marketing API Access Tier and individual scopes fit together.
