When your application requests private data, the request must be authorized by an authenticated user who has access to that data.
When your application requests public data, the request doesn't need to be authorized, but does need to be accompanied by an identifier, such as an API key.
Every request your application sends to the Google Partners API needs to identify your application to Google. There are two ways to identify your application: using an OAuth 2.0 token (which also authorizes the request) and/or using the application's API key. Here's how to determine which of those options to use:
If the request requires authorization (such as a request for an individual's private data), then the application must provide an OAuth 2.0 token with the request. The application may also provide the API key, but it doesn't have to.
If the request doesn't require authorization (such as a request for public data), then the application must provide either the API key or an OAuth 2.0 token, or both—whatever option is most convenient for you.
About authorization protocols
Your application must use OAuth 2.0 to authorize requests. No other authorization protocols are supported. If your application uses Google+ Sign-In, some aspects of authorization are handled for you.
Authorizing requests with OAuth 2.0
Requests to the Google Partners API for non-public user data must be authorized by an authenticated user.
The details of the authorization process, or "flow," for OAuth 2.0 vary somewhat depending on what kind of application you're writing. The following general process applies to all application types:
When you create your application, you register it using the Google Developers Console. Google then provides information you'll need later, such as a client ID and a
client secret.
Activate the Google Partners API in the Google Developers Console. (If the API isn't listed in the Developers Console, then skip this step.)
When your application needs access to user data, it asks Google for a particular scope of access.
Google displays a consent screen 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.
Some flows include additional steps, such as using refresh tokens to acquire new access tokens. For detailed information about flows for various types of applications, see Google's OAuth 2.0 documentation.
Here's the OAuth 2.0 scope information for the Google Partners API:
Scope
Meaning
https://www.googleapis.com/auth/partners
Read/write access.
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).
Tip: The Google APIs client libraries can handle some of the authorization process for you. They are available for a variety of programming languages; check the page with libraries and samples for more details.
Acquiring and using an API key
Requests to the Google Partners API for public data must be accompanied by an identifier, which can be an API key or an access token.
In the sidebar on the left, expand APIs & auth.
Next, click APIs.
Select the Enabled APIs link in the API section to see a list of all your enabled APIs.
Make sure that the Google Partners API is on the list of enabled APIs. If you have not enabled it, select the API
from the list of APIs, then select the Enable API button for the API.
In the sidebar on the left, select Credentials.
This API supports two types of credentials.
Create whichever credentials are appropriate for your project:
OAuth: Your application must send an OAuth 2.0 token with any request that
accesses private user data. Your application sends a client ID and, possibly, a client
secret to obtain a token. You can generate OAuth 2.0 credentials for web applications,
service accounts, or installed applications.
To create an OAuth 2.0 token, click Create new Client ID, provide the required
information where requested, and click Create Client ID.
A web application is accessed by web browsers over a network.
Applications that use JavaScript to access the Google Partners API must specify authorized
JavaScript origins.
The origins identify the domains from which your application can send API requests.
Applications that use languages and frameworks like PHP, Java, Python, Ruby, and .NET must
specify authorized redirect URIs. The redirect URIs are the endpoints to which the OAuth 2.0
server can send responses.
A service account is used in an application that calls APIs on behalf of an application
that does not access user information. This type of application needs to prove its own identity,
but it does not need a user to authorize requests. The
Google Accounts documentation contains
more details about service accounts.
An installed application runs on a desktop computer or handheld device. You can
create OAuth 2.0 credentials for several types of installed applications:
Android: You need to specify your Android app's package name and SHA1 fingerprint.
Show instructions
In the Package name field, enter your Android app's
package name.
In a terminal, run the
Keytool utility to get the
SHA1 fingerprint for your digitally signed .apk file's public certificate.
The Keytool prints the fingerprint to the shell. For example:
$ keytool -exportcert -alias androiddebugkey -keystore ~/.android/debug.keystore -list -v
Enter keystore password: Type "android" if using debug.keystore
Alias name: androiddebugkey
Creation date: Aug 27, 2012
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=Android Debug, O=Android, C=US
Issuer: CN=Android Debug, O=Android, C=US
Serial number: 503bd581
Valid from: Mon Aug 27 13:16:01 PDT 2012 until: Wed Aug 20 13:16:01 PDT 2042
Certificate fingerprints:
MD5: 1B:2B:2D:37:E1:CE:06:8B:A0:F0:73:05:3C:A3:63:DD
SHA1: D8:AA:43:97:59:EE:C5:95:26:6A:07:EE:1C:37:8E:F4:F0:C8:05:C8
SHA256: F3:6F:98:51:9A:DF:C3:15:4E:48:4B:0F:91:E3:3C:6A:A0:97:DC:0A:3F:B2:D2:E1:FE:23:57:F5:EB:AC:13:30
Signature algorithm name: SHA1withRSA
Version: 3
Copy the SHA1 fingerprint, which is highlighted in the
example above.
Paste the SHA1 fingerprint into the form where requested.
Click Create Client ID.
Chrome application: You need to specify the Application ID for your Chrome app or
extension. Use the Google Chrome
Identity API to obtain that ID.
iOS: You need to specify the app's Bundle ID and App Store ID.
Show instructions
The application's Bundle ID is the bundle identifier as listed in the app's
.plist file. For example: com.example.myapp.
The application's App Store ID is in the app's iTunes URL so long as the app was published in
the Apple iTunes App Store. For example, in the app URL
http://itunes.apple.com/us/app/google+/id447119634, the App Store ID is
447119634.
Other: The Developers Console does not require any additional information to
create OAuth 2.0 credentials for other types of installed applications.
Public API access:
A request that does not provide an OAuth 2.0 token must send an API key.
The key identifies your project and provides API access, quota, and reports.
To create an API key, click Create new Key and select the appropriate key type.
Enter the additional information required for that key type and click Create.
Create and use a server key if your application runs on a server. Do not use this
key outside of your server code. For example, do not embed it in a web page. To prevent quota
theft, restrict your key so that requests are only allowed from your servers' source IP
addresses.
Create and use a browser key if your application runs on a client, such as a web
browser. To prevent your key from being used on unauthorized sites, only allow referrals from
domains you administer.
Create and use an iOS key if your application runs on iOS devices. Google verifies
that each request originates from an iOS application that matches one of the bundle identifiers
you specify. An app's .plist file contains its bundle identifier. Example:
com.example.MyApp
Create and use an Android key if your application runs on Android devices. To do
so, you need to specify the SHA1 fingerprints and package names of the application using that key.
Show instructions
In a terminal, run the
Keytool utility to get the
SHA1 fingerprint for your digitally signed .apk file's public certificate.