What is the admob.readonly scope?

It's the AdMob API's read-only OAuth scope, granting read access to your AdMob data. The API also offers admob.report, which is scoped specifically to ad performance and earnings reports and is the tighter choice if reporting is all you need.

Is admob.readonly a sensitive scope?

Google classifies scopes into non-sensitive, sensitive and restricted tiers, and those classifications change over time. Check the current tier in Google's official OAuth 2.0 scope reference — that's the only authoritative source, and it determines whether you need a verification review.

What's the difference between admob.readonly and admob.report?

admob.readonly grants broader read access to AdMob data; admob.report is scoped to ad performance and earnings reports. If your app only pulls reporting, the reporting scope is the narrower and more appropriate request.

How do I avoid Google's restricted-scope security assessment?

Where possible, use a narrower scope that isn't in the restricted tier. A concrete example: drive.file grants access only to files your own app created, which covers export use cases without the full-Drive read access that triggers the stricter requirements.

Do I need OAuth verification for an internal tool?

Verification requirements depend on the scope tier and how your app is published, and some exceptions apply for internal use. Check Google's verification documentation for your specific case rather than assuming an internal tool is exempt.

Concepts

AdMob API OAuth scopes explained: admob.readonly, admob.report and app verification

TL;DR

The AdMob API offers two OAuth scopes, and picking the wrong one is the difference between a smooth launch and a verification review with a demo video attached. This covers what each scope grants, how Google's scope tiers work, and the general rule that saved us the most pain across a dozen Google integrations: request the narrowest scope that does the job, then check its tier before you build on it.

The two AdMob scopes

Scope	Grants
`https://www.googleapis.com/auth/admob.readonly`	Read-only access to your AdMob data
`https://www.googleapis.com/auth/admob.report`	Access to ad performance and earnings reports

If your app only pulls earnings and performance reporting, the reporting scope is the tighter request. `admob.readonly` is the broader read scope — we use it because our AdMob integration reads account, app and mediation structure alongside reporting, not just report output.

How Google's scope tiers work

Google sorts OAuth scopes into tiers, and the tier — not the API — decides what you have to do before real users can grant access.

Non-sensitive — no verification review needed for the scope itself.
Sensitive — requires review before accounts can grant it, typically including a justification and a video demonstrating the flow. Workspace admins can also restrict it.
Restricted — the strictest tier, and the one that can additionally require a third-party security assessment (CASA).

Tiers change. Google's own OAuth 2.0 scope reference is the only authoritative source for a given scope's current classification — check it there rather than trusting a blog post, including this one.

The lesson that saved us the most time

Across twelve native Google integrations, the single highest-leverage decision was choosing scopes by what the feature actually needs rather than by what's convenient.

A concrete example from our own code: for exporting reports to Google Drive we use `drive.file` — which grants access only to files our app itself creates — rather than `drive.readonly`, which would let us read the user's entire Drive. The narrow scope avoided a restricted-tier security assessment entirely, and it's genuinely the right permission for the job: an export tool has no business reading files it didn't create.

The same reasoning applies to AdMob. If you only need earnings reporting, don't request broad read access because it's simpler to reason about — the broader scope is a permission the user has to grant and you have to justify.

A practical checklist before you build

1List the exact API calls your feature makes — not the ones you might make later.
2Find the narrowest scope covering those calls in Google's OAuth 2.0 scope reference.
3Check that scope's tier in the same reference, and budget for verification if it's sensitive or restricted.
4Verify the consent screen shows what you expect with a real account before you ship — the wording users see is what determines whether they grant it.
5If a scope's tier makes it expensive, check whether a narrower scope or a different API surface avoids it, the way `drive.file` avoids the Drive restricted tier.

Skipping the integration work

If your goal is reading AdMob data rather than building an AdMob integration, connecting AdMob to an agent handles the OAuth entirely — see the AdMob platform page for what that covers (earnings, eCPM, fill, mediation waterfall by app and format), and the publisher skills for how the analysis is structured.

Frequently asked questions

What is the admob.readonly scope?: It's the AdMob API's read-only OAuth scope, granting read access to your AdMob data. The API also offers admob.report, which is scoped specifically to ad performance and earnings reports and is the tighter choice if reporting is all you need.
Is admob.readonly a sensitive scope?: Google classifies scopes into non-sensitive, sensitive and restricted tiers, and those classifications change over time. Check the current tier in Google's official OAuth 2.0 scope reference — that's the only authoritative source, and it determines whether you need a verification review.
What's the difference between admob.readonly and admob.report?: admob.readonly grants broader read access to AdMob data; admob.report is scoped to ad performance and earnings reports. If your app only pulls reporting, the reporting scope is the narrower and more appropriate request.
How do I avoid Google's restricted-scope security assessment?: Where possible, use a narrower scope that isn't in the restricted tier. A concrete example: drive.file grants access only to files your own app created, which covers export use cases without the full-Drive read access that triggers the stricter requirements.
Do I need OAuth verification for an internal tool?: Verification requirements depend on the scope tier and how your app is published, and some exceptions apply for internal use. Check Google's verification documentation for your specific case rather than assuming an internal tool is exempt.