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.
About authorization protocols
You must use OAuth 2.0 to authorize requests.
Authorize requests with OAuth 2.0
Following endpoints provided by Payments Reseller Subscription API must be authorized by an authenticated user.
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.
Accepted OAuth 2.0 Scopes
Sensitive OAuth 2.0 scopes
Please note that using the sensitive scopes in the production requires a formal review.
Non-sensitive OAuth 2.0 scopes
If you have a valid oauth scope that has access to the sensitive scopes above, it can be used for the eligibility APIs below.
Otherwise, we recommend a non-sensitive scope for a simpler user experience.
Google Services | Scope | Applicable APIs |
---|---|---|
All |
| partners.promotions.findEligible |
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.