When your application requests data, the request must be authorized by an authenticated user who has access to that data.
Every request your application sends to the People 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 Sign In With Google, some aspects of authorization are handled for you.
Authorizing requests with OAuth 2.0
Requests to the People 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 API Console. Google then provides information you'll need later, such as a client ID and a client secret.
- Activate the People API in the Google API Console. (If the API isn't listed in the API 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 People API:
To read the authenticated user's contacts, request one of the following scopes:
|https://www.googleapis.com/auth/contacts||Requests that your app be given read and write access to the authenticated user’s Google Contacts.|
|https://www.googleapis.com/auth/contacts.readonly||Requests that your app be given read access to the authenticated user’s Google Contacts.|
"Other contacts" Scopes
To read the authenticated user's "Other contacts", request the following scope:
|https://www.googleapis.com/auth/contacts.other.readonly||Requests that your app be given read access to the authenticated user’s "Other contacts".|
The people.get and people.getBatchGet endpoints do not require any scopes to read public Google profile data. To read the authenticated user's non-public profile data, request any of the following scopes:
The basic sign-in scope.
Requesting this scope when you sign in users does the following:
Requests that your app be given read access to the authenticated user's
You should not use the email address as a key to uniquely identify users, because users can change their email addresses. Instead use the profile source id.
|https://www.googleapis.com/auth/profile.agerange.read||Requests that your app be given read access to the authenticated user's age range in their Google profile.|
|https://www.googleapis.com/auth/profile.language.read||Requests that your app be given read access to the authenticated user's locales in their Google profile.|
|https://www.googleapis.com/auth/user.addresses.read||Requests that your app be given read access to the authenticated user's street addresses in their Google profile.|
|https://www.googleapis.com/auth/user.birthday.read||Requests that your app be given read access to the authenticated user's birthdays in their Google profile.|
Requests that your app be given read access to the authenticated user's
both the Google Account email address and any email addresses in their
Also see the related
|https://www.googleapis.com/auth/user.gender.read||Requests that your app be given read access to the authenticated user's genders in their Google profile.|
|https://www.googleapis.com/auth/user.organization.read||Requests that your app be given read access to the authenticated user's organizations in their Google profile.|
|https://www.googleapis.com/auth/user.phonenumbers.read||Requests that your app be given read access to the authenticated user's phone numbers in their Google profile.|
Reading domain data requires that the domain admin must have enabled external contact and profile sharing of domain-scoped data for their domain. To read the authenticated user's domain data, request the following scope:
|https://www.googleapis.com/auth/directory.readonly||Requests that your app be given read access to the authenticated user’s Directory.|
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
To acquire an API key:
- Open the Credentials page in the API Console.
This API supports two types of credentials.
Create whichever credentials are appropriate for your project:
OAuth 2.0: Whenever your application requests private user data, it must send an OAuth 2.0 token along with the request. Your application first 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.
For more information, see the OAuth 2.0 documentation.
API keys: 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.
The API supports several types of restrictions on API keys. If the API key that you need doesn't already exist, then create an API key in the Console by clicking Create credentials > API key. You can restrict the key before using it in production by clicking Restrict key and selecting one of the Restrictions.
To keep your API keys secure, follow the best practices for securely using API keys.
After you have an API key, your application can append the query parameter
key=yourAPIKey to all request URLs.
The API key is safe for embedding in URLs; it doesn't need any encoding.
Perform Google Workspace Domain-Wide Delegation of Authority
In enterprise applications you may want to programmatically access users data without any manual authorization on their part. In Google Workspace domains, the domain administrator can grant to third party applications domain-wide access to its users' data—this is referred as domain-wide delegation of authority. To delegate authority this way, domain administrators can use service accounts with OAuth 2.0.
For additional detailed information, see Using OAuth 2.0 for Server to Server Applications.