Stay organized with collections
Save and categorize content based on your preferences.
When your application makes requests that need identifying the user's Google Account. It must include an authorization token. The token also identifies your application to Google.
The following general process applies in the OAuth2 flow:
When you create your application, you register it using the Google API Console. Google then provides information you'll need later, such as a client ID and a client secret.
When your application needs access to user data, it asks Google for a particular scope of access.
Google displays an OAuth dialog to the user, asking them to authorize your application to request some of their data.
If the user approves, then Google gives your application a short-lived access token.
Your application requests user data, attaching the access token to the request.
If Google determines that your request and the token are valid, it returns the requested data.
Note that using the sensitive scopes in the production requires a formal review.
To request access using OAuth 2.0, your application needs the scope information, as well as information that Google supplies when you register your application (such as the client ID and the client secret).
OAuth Refresh Tokens
If your application needs access to Payments Reseller Subscription API beyond the lifetime of a single access token, it can obtain a refresh token. A refresh token allows your application to obtain new access tokens.
A refresh token typically expires in 6 months. While you can periodically refresh the tokens before they expire, there are other common scenarios where they can become invalidated. You should always take the end user to the consent flow when that happens.
[null,null,["Last updated 2025-07-23 UTC."],[[["\u003cp\u003eApplications must include an OAuth 2.0 authorization token when making requests to identify a Google account and the application itself.\u003c/p\u003e\n"],["\u003cp\u003eThe OAuth 2.0 flow involves registering your application, requesting access scopes, obtaining user authorization, and using the access token for data requests.\u003c/p\u003e\n"],["\u003cp\u003ePayments Reseller Subscription API has specific OAuth 2.0 scopes for Google One, YouTube, and Google Play Pass, which require formal review for production use.\u003c/p\u003e\n"],["\u003cp\u003eA non-sensitive scope (\u003ccode\u003eopenid\u003c/code\u003e) is recommended for eligibility APIs and offers a simpler user experience.\u003c/p\u003e\n"],["\u003cp\u003eRefresh tokens can provide extended access to the API but may introduce complexity and should be handled carefully considering their expiration and invalidation scenarios.\u003c/p\u003e\n"]]],["Applications needing user data must use OAuth 2.0 authorization. Register your application with Google to obtain a client ID and secret. The application requests a specific scope of user data access from Google. If the user approves, Google issues a short-lived access token. The application then uses this token to request user data. Sensitive scopes require formal review, but non-sensitive scopes like `openid` are available. Optionally, refresh tokens can be used for extended access but must be periodically renewed.\n"],null,["# Partner Managed Signup With OAuth Consent\n\nWhen your application makes requests that need identifying the user's Google Account. It must include an authorization token. The token also identifies your application to Google.\n\n### About authorization protocols\n\nYou must use [OAuth 2.0](/accounts/docs/OAuth2) to authorize requests.\n\n\u003cbr /\u003e\n\n| OAuth 1.0 is not supported. If your application uses OAuth 1.0, you must migrate to OAuth 2.0 to use this API.\n\n\u003cbr /\u003e\n\n### Authorize requests with OAuth 2.0\n\nFollowing endpoints provided by Payments Reseller Subscription API must be authorized by an authenticated user.\n\n- [partners.subscriptions.create](/payments/reseller/subscription/reference/rest/v1/partners.subscriptions/create)\n- [partners.subscriptions.entitle](/payments/reseller/subscription/reference/rest/v1/partners.subscriptions/entitle)\n- [partners.promotions.findEligible](/payments/reseller/subscription/reference/rest/v1/partners.promotions/findEligible)\n\nThe following general process applies in the OAuth2 flow:\n\n1. When you create your application, you register it using the [Google API Console](https://console.developers.google.com/). Google then provides information you'll need later, such as a client ID and a client secret.\n2. When your application needs access to user data, it asks Google for a particular scope of access.\n3. Google displays an OAuth dialog to the user, asking them to authorize your application to request some of their data.\n4. If the user approves, then Google gives your application a short-lived access token.\n5. Your application requests user data, attaching the access token to the request.\n6. If Google determines that your request and the token are valid, it returns the requested data.\n\n### Accepted OAuth 2.0 Scopes\n\n#### Sensitive OAuth 2.0 scopes\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n| Google Services | Scope | Applicable APIs |\n|------------------|-------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| Google Home | \u003cbr /\u003e \u003chttps://www.googleapis.com/auth/sdm.subscription.service\u003e \u003cbr /\u003e | [partners.subscriptions.create](/payments/reseller/subscription/reference/rest/v1/partners.subscriptions/create), [partners.subscriptions.entitle](/payments/reseller/subscription/reference/rest/v1/partners.subscriptions/entitle) |\n| Google One | \u003cbr /\u003e \u003chttps://www.googleapis.com/auth/subscriptions.thirdparty.googleone\u003e \u003cbr /\u003e | [partners.subscriptions.create](/payments/reseller/subscription/reference/rest/v1/partners.subscriptions/create), [partners.subscriptions.entitle](/payments/reseller/subscription/reference/rest/v1/partners.subscriptions/entitle) |\n| Google Play Pass | \u003cbr /\u003e \u003chttps://www.googleapis.com/auth/googleplay.pass.paymentsreseller\u003e \u003cbr /\u003e | [partners.subscriptions.create](/payments/reseller/subscription/reference/rest/v1/partners.subscriptions/create), [partners.subscriptions.entitle](/payments/reseller/subscription/reference/rest/v1/partners.subscriptions/entitle) |\n| YouTube | \u003cbr /\u003e \u003chttps://www.googleapis.com/auth/youtube.commerce.partnership.integrated-billing\u003e \u003cbr /\u003e | [partners.subscriptions.create](/payments/reseller/subscription/reference/rest/v1/partners.subscriptions/create), [partners.subscriptions.entitle](/payments/reseller/subscription/reference/rest/v1/partners.subscriptions/entitle) |\n\n\u003cbr /\u003e\n\nNote that using the sensitive scopes in the production requires a [formal review](https://developers.google.com/identity/protocols/oauth2/production-readiness/sensitive-scope-verification).\n\nTo request access using OAuth 2.0, your application needs the scope information, as well as information that Google supplies when you register your application (such as the client ID and the client secret).\n\n### OAuth Refresh Tokens\n\nIf your application needs access to Payments Reseller Subscription API beyond the lifetime of a single access token, it can obtain a refresh token. A refresh token allows your application to obtain new access tokens.\n\n\u003cbr /\u003e\n\n| Using refresh token is not required and may introduce extra complexity to your system.\n| A sample use case: by storing the refresh token in your system, and as long as the refresh token remains valid, your application can upgrade or downgrade a subscription without needing to guide the end user through another consent flow.\n\n\u003cbr /\u003e\n\nA refresh token typically expires in 6 months. While you can periodically refresh the tokens before they expire, there are other common [scenarios](https://developers.google.com/identity/protocols/oauth2#expiration) where they can become invalidated. You should always take the end user to the consent flow when that happens."]]