Ad Account OAuth Scopes: What a Tool Really Gets

Connecting an ad account to a third-party tool grants less than most people fear — and more than most people bother to check. On Google Ads, Google documents exactly one OAuth scope for the entire API, https://www.googleapis.com/auth/adwords (Google Ads API Docs — OAuth internals), paired with a developer token that is required in addition to the OAuth credentials (Google Ads API Docs — OAuth overview). Which account the tool can actually operate on is decided by a separate layer entirely: the login-customer-id header, which Google describes as “equivalent to choosing an account in the Google Ads UI after signing in” (Google Ads API Docs — Call structure).

Meta works differently. Its Marketing API exposes discrete named permissions through Facebook Login — chiefly ads_management (read and manage) and ads_read (reporting only) — but each permission only reaches ad accounts the app’s business owns or has been granted access to, and ads_management requires Meta App Review (Meta for Developers — Permissions Reference). Managing other people’s ad accounts requires Meta’s Advanced Access tier on top of the permission grant (Meta for Developers — Marketing API Access levels), and Advanced Access itself requires Business Verification for the requesting app (Meta for Developers — Permissions overview).

Two facts matter more than everything else on this page. First, real agency or partner access is not granted through an OAuth consent screen at all — it lives in each platform’s own account-access system, a separate layer. Second, revoking a connected app stops future access but does not delete the data the app already pulled; Google’s own help documentation says so explicitly. Every claim below is cited to Google or Meta primary documentation, re-verified on 31 July 2026 — and where we could not confirm something from a primary source, we say so rather than guess. That is also the model AdFlint’s connection flow is built on: you connect an ad account you own, and every permission involved is one you can inspect and revoke yourself.

Google Ads: one scope, three layers

Google’s REST authentication reference states it plainly: “The OAuth 2.0 scope to use for Google Ads API access is https://www.googleapis.com/auth/adwords” (Google Ads API — REST Auth reference). The OAuth internals page lists the same single scope, with no read-only or alternative Ads scope anywhere on the page. So a Google Ads consent screen does not tell you whether a tool will read or write — that is decided elsewhere. Three layers stack on every API call:

• The OAuth access token establishes who is calling. Per Google’s call-structure documentation, it “identifies either a manager account acting on behalf of a client, or an advertiser directly managing their own account” (Call structure).
• The developer token is a second credential, separate from the OAuth grant: “In addition to OAuth 2.0 credentials, a developer token is also required to make Google Ads API calls” (OAuth overview, page last updated 22 July 2026).
• The login-customer-id header establishes which account context the identity is acting in. When access flows through a manager account, the header is required and must be set to the manager account’s customer ID; omitting it produces AuthorizationError.USER_PERMISSION_DENIED (Call structure).

Google’s real permission system is the account access level

Because the API scope is uniform, the ceiling on what a person or partner can do in your account is set by Google Ads itself. Google defines five access levels: Email-only, Billing, Read-only, Standard, and Admin (Google Ads Help — About access levels). The access-management page adds a concrete marker of how much Admin can do: “For setting up monthly invoicing or applying for a credit line, ensure the user has ‘Admin’ access” (Google Ads Help — Manage access to your Google Ads account). When you evaluate a tool or an agency, this account-level role — not the OAuth scope string — is the thing to check. Our guide to ad account ownership covers why the account itself should always sit under your name.

Meta: named permissions, on a leash

Meta splits access into named permissions, each with its own definition in the Permissions Reference. The ad- and Page-related ones defined there:

The leash is the access tier. “If your app is only managing your ad account, standard access to the ads_read and ads_management permissions are sufficient” — but “if your app is managing other people’s ad accounts, you need advanced access” (Marketing API Access levels). Advanced Access requires Business Verification for the requesting app, and an annual Data Use Checkup may also be required (Permissions overview). It must then be maintained: at least 500 Marketing API calls in the trailing 15 days, with an error rate under 15% across the last 500 calls (Access levels). Meta also warns developers directly that over-requesting is self-defeating: “Selecting unneeded permissions is a common reason for rejection during app review” (Permissions overview).

Grants also decay. If an app does not use a permission for 90 days — usually due to user inactivity — the user must re-grant it (Permissions overview). And the tokens themselves expire: short-lived tokens last roughly one to two hours, long-lived tokens about 60 days, and Meta explicitly warns these lifetimes “may change without warning or expire early” (Facebook Login Access Tokens guide).

Agency access is a different mechanism, not a bigger OAuth grant

When an agency runs your Meta ads, that relationship is built in Business Manager’s asset-sharing system, not on a Facebook Login screen. Meta’s Business Asset Management overview draws the line: “Your business owns the assets or your business accesses them as an agency,” and the assets “can be owned by a business or shared to provide access to an agency” — framed as a way to “grant access to multiple assets all at once, without creating too many admins at the business level” (Business Asset Management overview). Inside that system, Business Manager roles set the ceiling: Admin gets read and write access to all connected assets and can add or remove people; Employee gets read access and cannot make changes except adding Pages or ad accounts they already administer (Business Manager API Get Started). The Business Manager API exists precisely for this: to “run campaigns on behalf of another company” (Business Manager API).

Google Ads is architecturally similar: a manager account (MCC) is linked to a client account through the Ads UI’s Access and security flow, and that link is a separate layer from any app’s OAuth scope. This distinction is why managed ad accounts and connected-account tools are structurally different products — and why AdFlint uses the connected-account model only: the account, the history, and the access controls stay yours.

Four myths about connecting an ad account

Myth 1: Revoking an app deletes the data it already pulled

Google’s Account Help page states the opposite: after revoking a linked app, “they can’t access your data anymore,” but “you may need to contact the developer of the app to request that they delete the data they already have” (Google Account Help). Revocation stops future access; it does not retroactively delete exported copies. Nothing we could verify on Meta’s side suggests its revocation behaves differently.

Myth 2: ads_management lets an app manage any ad account it wants

Meta’s own reference scopes the permission to “the Ads account it owns, or has been granted access to” (Permissions Reference). Reaching other businesses’ accounts additionally requires Advanced Access (Access levels) and a passed App Review. The permission is a capability, not a skeleton key.

Myth 3: Agencies get access through the same consent screen as apps

They do not. Meta’s docs describe agency access as Business-ID-based asset sharing with role-based limits — a Business Manager mechanism, not an OAuth scope grant. On Google, the manager-account link is created in the Ads UI, and even with it in place, an API caller still needs the correct login-customer-id to act in the client’s context (Call structure). If you ever need to unwind one of these relationships, our walkthrough on how to fire your ad agency covers the sequencing.

Myth 4: Google Ads has separate read-only and management scopes like Meta

Every official Google Ads API page we checked — the OAuth overview, OAuth internals, and the REST auth reference — surfaces exactly one scope for the entire API, and we found no read-only variant on any of them as of 31 July 2026. To be precise about the limit of that evidence: Google never states “there is only one scope, by design.” The absence of a second scope is an inference from three primary pages, not a quoted rule — and Google’s general OAuth 2.0 scopes list is silent on the question, since it contains no Google Ads entries at all. What is documented is where read-only enforcement lives when it exists: in the account’s own access levels, such as the Read-only role (About access levels).

How to revoke access, step by step

Remove a user or partner from one Google Ads account

1. Sign in to Google Ads.
2. Open the Admin menu.
3. Go to Access and security (ads.google.com/aw/accountaccess/users).
4. Before removing anyone, check which of the five access levels they hold — Email-only, Billing, Read-only, Standard, or Admin — so you know whether you are removing partial or total access.
5. Find the user or partner in the list.
6. In the Actions column, select Remove access (Google Ads Help).
7. For an invitation that has not been accepted yet, click Revoke in the Actions column instead.

Revoke a third-party app’s access to your whole Google Account

1. Sign in to your Google Account.
2. Go to myaccount.google.com/linkedapps.
3. Select the app.
4. Remove its access — Google confirms “you can review or remove the linked apps that have some access to your Google Account data at any time” (Google Account Help).
5. If you need previously-pulled data deleted, contact the app’s developer separately; revocation alone does not do it.

Meta: what we will not pretend to know

The mechanisms exist — app permissions are revocable from your account settings, and partner access is removable in Business Manager settings — but we could not extract the exact current click-paths from Meta’s consumer Help Center, which renders client-side and returned no readable body content during our verification pass. Rather than publish steps we could not verify against a primary page, we are flagging the gap. The permission definitions and access-tier rules above are all from Meta’s developer documentation, which did verify cleanly.

What we could not confirm

• The exact consumer click-path for revoking a specific app’s permissions from Facebook or Instagram settings, and the exact remove-partner flow in Business Manager (both pages returned titles without body content).
• A direct Google statement that the Ads API deliberately has no read-only scope; the single-scope finding is an inference from three official pages.
• Whether the ads_management row of Meta’s reference page itself displays a Business Verification requirement; the general rule that Advanced Access requires Business Verification is confirmed on the permissions overview, but its row-level display was not.
• Freshness timestamps for every Google page cited: the OAuth overview showed a 22 July 2026 update; the other pages do not surface visible timestamps.

What this means when you connect an account to AdFlint

AdFlint runs Google Ads and Meta ads exclusively on the connected-account model described above: you bring your own account via OAuth, you own it, and we never pool customers into a provider-owned account. Your card pays Google and Meta directly, and on the self-serve plans the fee is a flat monthly amount with 0% markup on ad spend — from Starter at $10/mo for up to $100/mo of ad spend, up the pricing ladder. Hard budget caps are enforced in software, and the guardrails we automate operate inside the same permission boundaries this article documents — nothing AdFlint does can exceed what the grant you approved allows, because the platforms enforce that boundary, not us. You can withdraw that grant yourself: on Google using the exact steps above, and on Meta from your account settings and Business Manager. The full connection flow, and the security model behind it, are laid out on how it works and our security page. There is a 7-day free trial if you want to see the consent screens for yourself before deciding anything.