AdMob API OAuth scopes explained: admob.readonly, admob.report and app verification
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 |
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).
Where the tier is actually written down (not where you'd expect)
This is the part that costs people an afternoon. Google's OAuth 2.0 scope reference — the long page listing every scope for every API — gives you the scope URL and a one-line description, and nothing else. For AdMob it lists admob.readonly and admob.report and describes both as "See your AdMob data". It does not say whether either one is sensitive. Checked September 2026.
The place the classification becomes visible is your own project. When you add a scope in the Google Cloud console's OAuth consent-screen configuration, the console sorts what you have added into non-sensitive, sensitive and restricted groups — so the answer for the scope you care about, on the date you care about, comes from the project you are actually going to ship.
- Add the scope first, decide second. Adding it to the consent screen costs nothing and is reversible; discovering the tier after you have built the feature is what hurts.
- The tier is per-scope, not per-API. Two scopes on the same API can land in different groups, which is the whole reason choosing the narrow one matters.
- Publishing status is a separate axis. A testing-mode app with a handful of test users behaves differently from one in production, so "do I need verification" has two inputs, not one.
admob.readonly for reads, because it walks account, app and mediation structure and not just report output. For writes it requests admob.monetization, which we treat as sensitive and which cleared Google's verification on 18 September 2026. Until that cleared, every user connecting saw the unverified-app interstitial — that is the concrete cost of a sensitive scope, and it lands on your users, not on you.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 — that page has the URLs and descriptions.
- 3Add that scope to your project's OAuth consent screen to see which tier it lands in, because the scopes reference does not say. Budget for verification if it comes back 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.fileavoids 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 does not publish the answer where people look for it. Its OAuth 2.0 scope reference lists admob.readonly and admob.report and describes both as "See your AdMob data" without stating a tier — we re-read that page in September 2026. The classification for your project, on today's date, shows up when you add the scope in the Google Cloud console's OAuth consent-screen configuration, which sorts what you have added into non-sensitive, sensitive and restricted. Add it there before you build on it; tiers change, and a blog post cannot be authoritative about one.
- Do I need OAuth verification for the AdMob API?
- It depends on the tier of the scopes you request and on your app's publishing status and user type, not on the API itself. If a scope lands in the sensitive tier, Google reviews it before regular accounts can grant it — typically a written justification plus a video of the flow — and until that clears, everyone connecting sees the unverified-app interstitial. That was our experience with admob.monetization, which cleared on 18 September 2026.
- 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.