YouTube Data API v2 Deprecation: Frequently Asked Questions

My application relies on comments, captions, or some other piece of functionality not present in the YouTube Data API v3. What should I do?

You can continue using the v2 API for comments and uploading video captions for now, and we'll be adding this functionality into the v3 API soon. While we don’t have specific dates yet, we will release that functionality so that developers have as much time as possible to migrate to v3.

For some other features, as YouTube overall continues to evolve, there will not be 100% feature parity between the v2 and v3 APIs. Please see the v3 API documentation for more details as to what functionality is supported in v3.

In v2, I’m able to authenticate using an email address + password via ClientLogin. How can I transition to OAuth 2.0?

Please see our Moving from ClientLogin to OAuth 2.0 guide.

How does quota differ in v2 vs. v3? What are the similarities?

Both v2 and v3 make use of a cost-based quota system in which some operations (like uploads) consume a larger amount of quota than others (like searches).

The most significant difference between the v2 and v3 systems is that v3 provides a global quota pool, which v2 did not do. In v2, requests made with a single developer key but coming from distinct IP addresses or from distinct authenticated users couldn’t cause global quota errors for that developer key—the worst that would happen would be a localized quota error associated with the IP address or YouTube channel.

In v3, there is a global quota pool (of 50 million units/day), and all API calls that are associated with a specific project in the Developers Console decrement quota from that pool. Therefore, it is theoretically possible for a single IP address or channel to consume all of the quota associated with an API registration, which could lead to an outage that affects other users.

However, you can still protect against a single user draining the global quota pool. This public documentation explains how to define and apply stricter, per-user rate limits.

The Data API v2 supported anonymous API access for read-only queries, like video searches. Why do I need to register to make read-only calls in v3?

The v3 API is built on top of the modern Google API infrastructure, in which the usage of many different APIs can be tied to a specific Developer Console registration. This presents developers with a unified view of the Google technologies they are using.

For API calls that only access publicly available data, such as search queries, API clients can specify a simple API key when making an API request. API calls that access private user data must specify OAuth 2.0 tokens.

Developers can obtain simple API keys and the credentials needed to generate OAuth 2.0 tokens in the Google Developers Console. Developers can also test out the API without creating a project first by using the APIs Explorer.

Can I continue using the same client libraries I used with v2 after migrating to v3?

The v3 API is fundamentally different from v2, and there’s a new set of client libraries to use. They are all available from, and they all contain native support for OAuth 2 authorization.

I previously used the YouTube Insight API, which is part of v2. What’s my alternative?

We recommend that all developers migrate from the YouTube Insight API, which was deprecated separately in September 2013, to the new YouTube Analytics API.

I rely on using the GData API (v1 or v2) for RSS/Atom feeds of YouTube videos. Do I have any alternative once they’re deprecated?

At this time, there is no direct alternative. We recommend providing your application’s users with the ability to manage and retrieve their YouTube subscriptions using the methods of the YouTube Data API v3’s subscriptions service.

Since I'm still using some v2 features that aren't available yet in v3, I need to access both API versions in the same application. What are some best practices?

You can use the OAuth 2.0 support in the v3 client libraries to obtain authorization tokens that will work for write operations in both v2 and v3. Any token that has either the or scope will work for both APIs.

For API calls that do not require OAuth 2.0 tokens, obtain a v3 API key from and use it for both v2 and v3.

We recommend migrating your app to use the v3 API whenever possible even if you do still need to call the v2 API for some functionality. By doing so, you will enable your app to use the more robust functionality that v3 offers. You will also simplify your future migration efforts when the v2-only features that will be supported in v3 are eventually released.