Complying with YouTube's Developer Policies

If you use YouTube's API services, you must adhere to our:

As a developer, you must familiarize yourself with these policies. This article provides examples that provide additional clarifications about specific policies, and answers some frequently asked questions.

If, after reviewing this article and the policies linked to above, you’re unsure whether your service is allowed, please apply for an API Compliance Audit, and include a clear summary that mentions any end users in the audit form.

Respect user privacy.

What this means: Don’t violate user privacy, harvest user data, or use the API to surveil users. Your app must have a privacy policy that protects users and complies with Google’s privacy policies. Once you have a user’s permission to access or store their data, that user must continue to have control over what happens to that data. You need to make it easy for users to request deletion of their personal data. More information can be found here.

Examples

Don’t use YouTube’s API to:

  • Harvest, track, infer, derive or store information that can be used to identify a user without their consent. Examples include (this is not a complete list):
    • Full names or usernames
    • Passwords
    • Facial recognition data
    • Contact information including email or phone number
    • Online activity such as browsing history
      • Example: Using YouTube’s API to create an app that tracks a user’s viewing history, location or browsing habits without their knowledge or consent.
    • Harvest, track, infer, derive or store the following about a user without their consent. Examples include (this is not a complete list):
      • Health information
      • Gender identity
      • Sexual orientation
      • Political affiliation
      • Religious affiliation or belief
      • Race or ethnicity
      • Immigration status
      • Financial status
      • Criminal history
      • Trade union membership or organization
    • Facilitate surveillance -- for example, tracking their location, browsing history or other online activity without their consent.
    • Restrict, filter, or prohibit a user’s access to content on YouTube without their knowledge or consent.
    • Allow any unauthorized third parties to access, use, or download any data noted here.
    • Store a user’s information indefinitely. If a user requests that you delete their data or if you’re unable to verify their authorization, you must do so within 30 days.
    • Use, request, or store a user’s login credentials (username and password)

Only offer metrics that are available via YouTube’s API services.

What this means: Don’t use YouTube’s API to offer independently calculated or derived metrics or data that replace or provide new data that isn’t available via YouTube’s API services. More information can be found here.

Examples

Don’t use YouTube’s API to:

  • Display metrics that replace those offered by YouTube’s API services.
  • Display metrics that inaccurately reflect those offered by YouTube’s API services.
  • Combine data from YouTube’s API with data from other sources. If you provide data that is derived from sources other than YouTube’s API alongside data that you get from YouTube’s API, you must make the difference clear to the user.
    • Example: Providing a "user engagement" metric that includes engagement from YouTube in combination with other platforms.
  • Display data from YouTube next to data from other platforms without clarifying the difference between the types and sources of data.
  • Compile or aggregate authorized API data unless you are making the compiled API data viewable ONLY to the content or channel owner or one of their authorized representatives.
  • Gain insights into the number of users, number of videos uploaded, watch time, financial performance, or any other aspect of YouTube’s business.
  • Make any claims on whether a video or channel is safe or suitable to watch or advertise against.
  • Estimate the watch time or unique reach of a channel or video.
  • Estimate the number of paid views, sponsored views, or average advertising CPM of a video.
  • Estimate audience affinities, demographics, or audience composition of a channel or video.
  • Infer or estimate the content category/type of a video or channel; you may only use the content type returned by the YouTube API.
  • Estimate the monetization status of a video or channel, or make claims on whether a video or channel should be monetized.
  • Merge or combine YouTube API data with any other data.
  • Return information like the total number of video views and offer a number different from the number provided by YouTube’s API.
  • Infer or project financial performance of a YouTube channel.
  • Gamify channel performance by ranking or tracking views between different channels, or generally stoking creator rivalries.
  • Estimate viewer satisfaction or dissatisfaction with a particular YouTube channel.
  • Calculate and assign custom "scores" to channels based on independently calculated averages or ratios -- for example, average view count, comment count, or overall brand suitability.

Acceptable metrics

Acceptable metrics are those that use only YouTube API data and combine them via simple mathematical calculations (combine them via addition, subtraction, averages, multiplication, division). These metrics must not incorporate any other external data sources. This allows us to ensure that the represented data is accurate.

Examples

  • Average daily views in a month
  • Average video duration
  • Number of subscribers gained or lost
  • Average number of new subscribers in a month
  • Total views in a group of videos/channels
  • Top viewed videos/channels sorted by views, likes/dislikes, subscribers
  • Graphs visualizing raw metrics, e.g: increase in views, subscribers, likes/dislikes

Your API service must reflect a user’s standard experience on YouTube.

What this means: Any service using the YouTube API can’t diminish or remove features that are part of a user’s standard experience on YouTube, such as captions, volume controls, etc. More information can be found here.

Examples

Don’t use YouTube’s API to:

  • Modify, add to or block the standard playback function of the YouTube video player. Some examples include:
    • Blocking a link that would normally appear in the YouTube player from appearing in your application.
    • Disabling or blocking Related Video links from appearing after the video completes.
    • Removing or altering the video metadata. In general, video metadata such as thumbnail and title must be visible to the viewer and unmodified. The video thumbnail must not be altered.
      • Note: Custom play buttons over the YouTube thumbnail are acceptable, but tapping must initiate playback.
    • Links must open in the YouTube application whenever the application is available on a user’s device, or if not installed, via the system web browser.
    • Blocking the standard features of a YouTube player (like the settings wheel) from appearing in your API service.
    • Overriding the platform-specific rendering of the YouTube video player.
      • Example: Mobile optimized UI must appear on mobile apps and devices.
    • Restricting ads from playing in your API service when they would otherwise play on YouTube or in an embedded video.
    • Note: Overlays for the purposes of obtaining user consent or playback controls (e.g. mute, full screen, play, pause, etc.) are acceptable so long as they do not conflict with the YouTube player UI elements.
  • Restrict YouTube’s ability to verify from where the playback occurs.
    • Example: In the case of mobile applications using a WebView to host the YouTube IFrame SDK web player, failing to accurately represent the name of your application (e.g. com.company.appname) accurately as HTTP Referer header.
    • Example: Interfering with other playback context information necessary for view verification (including cookies) being sent to YouTube.
      • For privacy sensitive developers who deem it necessary, a user consent flow with link to Google’s Privacy Policy is acceptable.
  • Apply any restrictions or block access to a user watching a video. If a user has to do anything besides clicking the play button, there’s a good chance that you’re violating this policy. An example includes:
    • Example: Restricting access to a video by requiring a user to complete a survey, download an app, subscribe to a channel, share a video on a social media platform, leave comments, or do anything other than click the "Play" button in order to watch a video they chose to watch.
  • Incentivize, reward, coerce, or provide compensation to users for watching a video. A user’s decision to watch a video needs to be their own choice.
    • Example: Offering the chance to win a prize or offering financial compensation in exchange for a user watching a video through your API service.
  • Block, modify or replace advertisements that play through the YouTube API service.
  • Allow users to download videos for offline play outside of the YT Premium experience.
  • Offer users the ability to download or separate audio tracks or allow users to modify the audio or video portions of a video.
    • Example: Using YouTube’s API to separate or isolate video or audio components from a video. This might include an API service that offers mp3 files of audio that appeared in a video and promotes themselves in this context.
  • Allow for background play of the YouTube video player.
    • Example: Using YouTube’s API to allow videos to play even when your API service window is closed or minimized.

Your API service must add sufficient independent value.

What this means: Don’t use our API to re-create YouTube (e.g. don’t clone, mimic, modify, or reduce standard YouTube features). If your API service mimics any of YouTube’s user experiences, it must add sufficient independent value. Independent value means providing users with added functionality that is not available via the YouTube API today or was not available at the time of API access request, and is otherwise compliant with YouTube’s TOS. More information can be found here.

Examples

If your API service mimics any of YouTube’s user experiences, users need to have a reason to continue to engage with or utilize your API service when you take away what you are getting by accessing YouTube’s API services. You also cannot charge people a fee for services that are offered free of charge on YouTube.

  • Example of what’s allowed: A Search engine that lists YouTube videos alongside videos available on other platforms while clearly distinguishing them from what’s on YouTube is a good example of an API service that provides independent value.
  • Example of what’s allowed: An API service that provides YouTube video captioning services for the hearing impaired is a good example of providing independent value.
  • Don’t use YouTube’s API to create websites or apps or display video search results that make it difficult to distinguish between your website or app and websites or apps created by YouTube.
    • Example: Using YouTube’s API to mass aggregate embedded videos, creating an identical copy of YouTube. If a user is likely to mistake your site for YouTube’s, there’s a good chance it violates our TOS.

Don’t allow users to circumvent YouTube restrictions, or violate our Community Guidelines.

What this means: Your service can’t be specifically designed to allow you or your users to get around restrictions YouTube places on their channel. Your API service also can’t let users do activities that violate our community guidelines, Terms of Service, or YouTube Partner Program. If you use YouTube’s API to allow users to upload videos, you must have them certify that their content complies with the community guidelines. Videos are subject to removal if found to be violative. Your service can also be subject to penalties if it encourages or incites violative behavior. More information can be found here.

Don’t spread API access across multiple or unknown projects.

What this means: You can’t create multiple apps/sites or create multiple Google Cloud projects for use across multiple apps/sites to artificially acquire more API quota (aka "sharding") for a single API service or use case. "Use case" is defined as a consistent set of analyses, features, or actions performed via a service. Requests for API quota increase must follow our standard process. An application’s developer team is allowed to have separate API keys for test, dev, and prod environments. More information can be found here.

Examples

  • Don’t create multiple Google Cloud projects for the same API service or use case in an attempt to deceptively acquire an API quota that is higher than the one your project was assigned.
  • It is acceptable to have a separate API Project for each different use case of your API service. Examples include:
    • One API project for your iOS app, a separate API Project for your Android app.
    • One API project for a production server, one for a development server.
    • One API project for your user-facing API service, one API project for internal system analytics.