YouTube OAuth Scopes Explained for Creator Data Access

YouTube scopes sit on Google's OAuth infrastructure rather than on a YouTube-specific one, and that inheritance produces behaviour no other social platform has.

The scopes are URLs. Every one of them is classified as sensitive, including read-only. Users can grant part of your request. And Google will revoke your refresh tokens for reasons that have nothing to do with your app, such as the creator changing their account password.

What follows is every YouTube scope with the access it grants, the verification tier it sits in, and the 3 Google-specific behaviours that break integrations built as though YouTube worked like Instagram. Everything here is from Google's developer documentation as of July 2026.

How do YouTube scopes differ from other platforms?

4 differences, and each one has caught somebody out.

• Scopes are full URLs. The value you send is https://www.googleapis.com/auth/youtube.readonly in full. Shorthand does not work.
• All YouTube scopes are sensitive. Meta and TikTok have unrestricted entry-level scopes. YouTube does not, so even a read-only integration needs Google app verification before people outside your test users can connect cleanly.
• Partial grants are allowed, as on TikTok. Google documents checking the scope property of the token response, and on Google it is a space-delimited list rather than comma-delimited.
• Tokens die for external reasons. Google revokes all refresh tokens carrying YouTube scopes when the user changes their Google account password. Nothing your app does causes it and nothing your app does prevents it.

If you are building across several platforms, we mapped the equivalents in Instagram API permission scopes and TikTok API permission scopes.

What does each YouTube Data API scope unlock?

These are the scopes for reading and managing channel content. All paths below are prefixed with https://www.googleapis.com/auth/.

Scope	What it grants	Notes
youtube.readonly	View the authenticated user's YouTube account	The read scope for channel and video metadata. Sensitive, so it still needs verification
youtube	Manage the authenticated user's YouTube account	The broad read and write scope. In the Analytics API, channel owners use it to manage Analytics groups and group items
youtube.force-ssl	Read and write over an enforced SSL connection	Covers a wide set of methods on its own, including videos.insert, videos.list, channels.list, playlistItems.insert, commentThreads.insert and commentThreads.list, comments.insert, liveBroadcasts.list and liveChatMessages.insert
youtube.upload	Upload videos to the authenticated account	Narrower than force-ssl. If you already request force-ssl you generally do not need this as well
youtubepartner	View and manage YouTube assets and associated content	Content owner level access. Relevant to multi-channel networks and rights management rather than to a single creator integration

The most useful line in that table is the force-ssl row, and it is a rejection risk as much as a capability. Google's method documentation lists youtube.force-ssl as sufficient for a broad range of calls, and reviewers reject applications that request youtube, youtube.readonly and youtube.upload alongside it, because the broader scope already covers them. Requesting more than you need does not make approval more likely on YouTube. It makes it less likely.

What do the Analytics and Reporting scopes return?

2 scopes, and the difference between them is money.

Scope	What it returns	Use it when
yt-analytics.readonly	YouTube Analytics reports covering user activity metrics such as view counts and rating counts	You need performance data and no revenue figures
yt-analytics-monetary.readonly	Both monetary and non-monetary reports. Includes user activity metrics plus estimated revenue and ad performance metrics	You need earnings. This is the only scope that reaches them

If your product verifies creator income, underwrites an advance, or reports earnings back to a creator, yt-analytics-monetary.readonly is not optional and there is no substitute. It is also the scope a creator is most likely to hesitate over at the consent screen, which is a product design problem as much as a technical one: explain what you do with the figure before you ask for it.

Note that the monetary scope is a superset. It returns the activity metrics as well, so requesting both scopes is redundant and adds another item to the consent screen for no gain.

The same 2 scopes serve the YouTube Reporting API, which delivers bulk reports rather than real-time queries. Choosing between the Analytics API and the Reporting API is a delivery decision, not a permission one.

If you want YouTube earnings and audience data without running Google verification yourself, our per-platform field list is public. See the coverage list

Why does every YouTube scope need verification?

Because Google classifies them all as sensitive, including the read-only ones. Until your app is verified, anybody outside your registered test users sees an unverified app warning at the consent screen, and a large share of them will stop there.

2 consequences that are easy to miss during development.

• Your team will never see the warning. Test users are exempt, so the flow looks clean right up until a real creator tries it. This is the same shape of surprise as Meta's Standard Access and TikTok's sandbox.
• Google Workspace accounts can be blocked entirely. A Workspace administrator can prevent non-approved third-party apps from connecting, and the flow fails with admin_policy_enforced. If your creators use managed Google accounts, verification is not the only gate.

One more piece of guidance from Google's own documentation that is worth taking seriously: there is an inverse relationship between the number of scopes you request and the likelihood of obtaining consent. Every extra line on the consent screen costs you connections.

How do you handle a partial grant?

Read the scope field in the token response and build your feature set from what you were actually given. Google returns it as a space-delimited, case-sensitive list.

// Token response. Note the space-delimited scope string.
{
  "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
  "expires_in": 3920,
  "token_type": "Bearer",
  "scope": "https://www.googleapis.com/auth/yt-analytics.readonly
            https://www.googleapis.com/auth/youtube.readonly",
  "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
}

BASE = "https://www.googleapis.com/auth/"

CAPABILITY = {
    "channel_metadata": BASE + "youtube.readonly",
    "performance":      BASE + "yt-analytics.readonly",
    "revenue":          BASE + "yt-analytics-monetary.readonly",
    "publishing":       BASE + "youtube.force-ssl",
}

def capabilities(token_response):
    # Google returns a SPACE-delimited list, not comma-delimited.
    granted = set(token_response["scope"].split(" "))
    # monetary is a superset of activity metrics
    if CAPABILITY["revenue"] in granted:
        granted.add(CAPABILITY["performance"])
    return {name: scope in granted for name, scope in CAPABILITY.items()}

caps = capabilities(resp)
if not caps["revenue"]:
    hide_earnings_panel()
    prompt_reconnect("earnings reporting")

The superset handling in the middle matters. A creator who granted only the monetary scope has also granted you the activity metrics, and treating those as missing would hide data you are entitled to.

Why do YouTube connections break on their own?

Because Google revokes all OAuth refresh tokens containing YouTube scopes when the user changes their Google account password. This is the single most important operational fact on this page.

Think about what that means at scale. A creator updates their Google password for reasons entirely unrelated to your product, and their connection to you dies silently. No notification reaches you. The next scheduled sync fails. If your product reports on 5,000 connected channels, a slow drip of password changes across that population is a permanent background failure rate you cannot engineer away.

What you can do is handle it properly rather than treat it as a bug.

1. Separate revocation from expiry in your error handling. An expired access token needs a refresh call. A revoked refresh token needs the creator to reconnect, and retrying it forever just fills your logs.
2. Show disconnected channels in your interface. The creator has no idea their password change broke anything, so the prompt has to come from you.
3. Alert on refresh failure rate, not on individual failures. Individual revocations are normal. A step change in the rate is a signal that something else broke.
4. Never show stale data as current. If the connection died 3 weeks ago, the figures on screen are 3 weeks old and the creator deserves to know that.

What flows does YouTube not support?

2 that teams commonly plan around before checking.

• Service accounts do not work for the YouTube Analytics and Reporting APIs. There is no server-to-server path. Every channel you read requires an interactive grant from a human who owns it.
• The device flow is not supported for these APIs either. If you are building for a device without a browser, this is a hard constraint rather than an inconvenience.

The service account limitation is the one that reshapes architecture. It means you cannot centralise YouTube access behind a single set of credentials, and every creator in your product is a separate OAuth relationship with its own token lifecycle and its own revocation risk.

Which scopes does your product need?

What you are building	Scopes	Why
Channel and video display	youtube.readonly	Metadata only. The narrowest useful read scope
Creator analytics dashboard	youtube.readonly, yt-analytics.readonly	Performance metrics without touching revenue
Income verification or creator lending	yt-analytics-monetary.readonly	The only route to estimated revenue. Superset, so no separate activity scope needed
Publishing and comment management	youtube.force-ssl	Covers insert, list and comment methods on its own. Do not add the overlapping scopes
Bulk reporting at scale	yt-analytics.readonly or the monetary version	Same scopes, delivered through the Reporting API instead
Content owner or MCN tooling	youtubepartner	Asset and rights management across many channels

Is scope the same as quota?

No, and conflating them produces a working integration that stops at lunchtime.

Scope decides whether you are allowed to make a call. Quota decides how many calls you can afford. YouTube Data API projects run on a quota unit system with a default daily allocation, and the cost per call varies enormously: a metadata read is cheap and a search call is 100 times more expensive.

So a product with perfect scope coverage can still fail at scale because its search-heavy design burns the daily allocation. Design your read patterns around the quota cost table before you optimise anything else, and remember that spinning up extra Google Cloud projects to multiply the free quota breaks the terms of service.

What does no scope unlock?

What you cannot get	Why
Analytics for a channel you do not own	Every analytics scope is scoped to the authenticating channel owner. There is no permission that returns another creator's watch time, audience or revenue
Revenue for anyone but the authorising channel	yt-analytics-monetary.readonly returns the authorising account's estimated revenue only
Server-to-server access	Service accounts are not supported for the Analytics and Reporting APIs. A human grant is required for every channel
A token that survives a password change	Google revokes refresh tokens with YouTube scopes when the account password changes. No scope prevents it

The first row is the one that reshapes influencer products. If a brand wants audience demographics or earnings for a creator they are merely considering, no YouTube scope reaches it, because the data belongs to the channel owner. That boundary is the same on every major platform and we set it out in authenticated versus public social data.

What are the most common YouTube scope mistakes?

• Requesting overlapping scopes. Adding youtube, youtube.readonly and youtube.upload next to youtube.force-ssl is a documented rejection cause.
• Requesting both analytics scopes. The monetary scope already includes the activity metrics.
• Splitting the scope string on commas. Google returns a space-delimited list. TikTok uses commas. Copying the parsing logic between them silently fails.
• Planning on service accounts. Not supported for Analytics and Reporting. Discover this at design time rather than at integration time.
• Treating a revoked token as a retryable error. It will never succeed. The creator has to reconnect.
• Testing only with test users. They never see the unverified app warning that every real creator will.

Where does Phyllo fit?

We run this layer for you. When a creator connects their YouTube channel through your product, Phyllo's social data API handles the Google verification, the scope selection, the partial grant logic and the revocation handling, and returns normalised fields through the same schema that serves 25+ other platforms.

That includes the fields behind the monetary scope. Creator income data is the reason most fintech and creator lending products come to us, because estimated revenue is not available from any public source and building the YouTube path alone means owning Google verification and a permanent revocation failure rate. Per-platform coverage is public at getphyllo.com/coverage and the API reference needs no sales call.

Where we are not the answer: if YouTube is your only platform and you have engineering capacity, request the scopes yourself. Google charges nothing for the API and the documentation is among the best in this category. The case for a layer starts at the second platform, and the comparison across the major 4 is in which platform API to integrate first.

The short version

Request the narrowest scope set that covers what your product visibly does, because YouTube penalises over-requesting at both the review stage and the consent screen. If you need publishing, youtube.force-ssl usually covers it alone. If you need earnings, yt-analytics-monetary.readonly is the only option and it already includes the activity metrics.

Then build for the 2 things that make YouTube different: users who grant part of your request, and tokens that die when somebody changes a password you will never know about. Handle both as normal operating conditions rather than as errors, and the integration stays healthy.

Want YouTube performance and revenue data without owning Google verification and a permanent revocation rate? Get a demo