Sign in to ATL Ads Manager

• public_profileUser name and profile picture

  The user's display name and Facebook avatar let us greet them in the sidebar, attribute every action they take to a recognisable identity in the audit log, and label them clearly on the account screen. Without this scope the UI can only show a numeric Facebook ID, which makes operator mistakes (acting on the wrong Page, mis-attributing an audit row) much more likely.

• emailEmail for contact and identification

  The signed-in user's primary email is recorded so we can contact them about account-level events — data-deletion confirmation, security notifications, and (in a future release) alert digests routed off-platform. We never send marketing email and never sell or share the address. Without this scope recovery and incident-notification flows degrade to in-app-only.

• ads_managementCreate, edit and delete campaigns / ad sets / ads

  Operators use this app to run their own paid advertising programmes end-to-end without leaving for Meta's Ads Manager. The /campaigns list and the /campaigns/[id] detail screen exercise create, edit, pause, resume and delete on campaigns, ad sets and ads. Without this scope the entire mutation surface for paid advertising goes read-only and the product loses its primary differentiator.

• ads_readRead ad metrics and reports

  Reading ad-performance metrics is the foundation of the /dashboard, /reports and /campaigns/[id] screens. We pull spend, impressions, reach, clicks, CTR, CPC, CPM, frequency, and per-event conversion counts at the account, campaign, ad-set and ad levels so operators can decide where to allocate budget. Without this scope every chart and KPI tile in the app would be empty.

• business_managementAccess Business Manager: ad accounts, businesses, assets

  Operators typically manage multiple ad accounts and Pages through Meta Business Manager. The /settings page surfaces every Business portfolio the signed-in user belongs to (call: GET /me/businesses) with verification status, vertical and primary Page — operators use this to confirm the right BM is connected before kicking off campaigns. The same scope unlocks the multi-account picker on /dashboard, /reports and the campaign list, where assets visible across BMs are enumerated as one cohesive surface. Without this scope only personal ad accounts would be visible and the Business portfolios card would be empty.

• read_insightsRead Page and ad insights

  Page-level insights (impressions, post engagements, total fans) are surfaced at the top of every /pages/[pageId] screen so operators can judge whether organic reach is healthy before deciding to boost a post. The data is shown read-only and is not exported anywhere outside our UI. Without this scope the Page detail page loses its three insights tiles.

• pages_show_listList the Pages the user manages

  We enumerate the Pages the signed-in user manages so the /pages grid, the Page picker inside the 'Promote a Page post' ad-creation flow, and the unified Inbox can all be wired to the correct Page-scoped access tokens. Without this scope the application would have no idea which Pages the user is allowed to interact with and the whole Pages surface would be inaccessible.

• pages_read_engagementRead posts, comments and reactions on a Page

  Reading posts, comments and the six-type reaction breakdown (LIKE / LOVE / WOW / HAHA / SAD / ANGRY) is what populates the post feed on /pages/[pageId] and the cross-Page stream at /inbox. Reaction counts in particular are pulled with summary(total_count) sub-queries so we never enumerate individual reactors. Without this scope the engagement views would be empty and the moderation flow could not be opened on any comment.

• pages_read_user_contentRead user-generated content (UGC) on a Page

  User-generated content — the comments left by the public on the operator's Pages — is what the /inbox surface aggregates across every managed Page. We pull message body, author name, hidden flag and timestamp so moderators can triage from one place instead of switching between Page tabs inside Facebook. Without this scope the unified Inbox cannot be assembled.

• pages_manage_metadataEdit Page settings and subscribe to webhooks

  Editing the About and Description copy of a managed Page from the /pages/[pageId] settings card is the action this scope unlocks today; we do not subscribe to Page-level webhooks beyond the signature-verified receiver that already lives at /api/webhooks. Without this scope the Page-settings card becomes read-only.

• pages_manage_postsCreate, edit and delete posts

  Composing, editing and deleting posts from the /pages/[pageId] composer is a headline feature for operators who want their workflow to stay inside this app. Each post is written with the Page access token via the same /feed endpoint Meta exposes officially. Without this scope the composer would have to bounce users back to facebook.com to publish anything.

• pages_manage_engagementReply to comments and like as the Page

  Replying to a comment as the Page, hiding spam, and deleting abusive comments are the actions the /pages/[pageId] post list and the /inbox stream exercise inline. We use page-scoped access tokens for these mutations so each action is correctly attributed to the Page, not to the operator's personal account. Without this scope the inbox triage flow becomes read-only and operators cannot act on the comments they read.

• pages_manage_adsRun ads (boost post) on behalf of the Page

  When an operator decides a Page post is worth promoting, the /pages/[pageId] Boost button creates the campaign + ad set + ad chain pointing at that post's object_story_id, in PAUSED status, ready for them to review before activating. The Page-level scope is what authorises us to create ads that reference that Page. Without this scope the Boost CTA on every post would have to be removed.

By continuing, you agree to our Terms of Service and Privacy Policy.