Set up Google Cloud and OAuth

Access to the Google Health API is provided through Google Cloud. To enable the API and authorize a Google Account, you'll need a Google Cloud project.

Whether you are an existing Fitbit API developer, or new to the Google Health API, you'll need to complete this step in order to make calls to the API.

Create a project and an OAuth client

Use the Enable the API and get an OAuth 2.0 Client ID button to enable the Google Health API and get an OAuth 2.0 Client ID:

  1. If you have an existing Google Cloud project project that you would like to use for the Google Health API, make sure you are logged into the administrator account for that project first. Then select the existing project from the list of available projects after clicking the button. Otherwise, create a new project.
  2. Select Web Server when it asks "Where are you calling from?".
  3. Enter https://www.google.com as the value for Authorized redirect URIs. A redirect URI is required to obtain an Authorization Code using OAuth 2.0.
  4. Once setup is complete, copy the OAuth 2.0 Client ID and Client Secret values, and download the Credentials JSON to your local machine.
Enable the API and get an OAuth 2.0 Client ID

If you want to manually set up your Google Cloud project, or verify the setup and retrieve your credentials again:

  1. Enable Google Health API on the API Enablement page.
  2. Get an OAuth 2.0 Client ID on the Credentials page.

For more information on setting up OAuth 2.0 using the Google console, see Using OAuth 2.0 to Access Google APIs.

Add test users

By default, newly created OAuth clients are in an unverified state with a cap of 100 users for both testing and production purposes. To enable authorization during this period, you must manually add each user's email address to the Test users list in your project configuration.

Update the list of test users on the Audience page:

  1. On this page, you should see the "Publishing status" set to Testing, and the "User type" set to External.
  2. Under the section "Test users", click + Add users. Enter the email address for any test users that should be allowed to grant your app permission to access their health data.
  3. Click Save.

Supporting more than 100 users with the Google Health API requires completion of a third party security review. Additional information can be found in the OAuth App Verification Help Center.

Add scopes

You must specify the scopes your client is allowed to call on the Data Access page:

  1. On this page, click Add or remove scopes.
  2. In the API column, search for "Google Health API". Select the scopes you need for your application.
  3. After selecting all the scopes you need, click Update to return to the Data Access page.
  4. Click Save.

You have finished setting up your client ID and should now be able to make calls to the Google Health API.

OAuth2 client libraries

The list of available OAuth2 client libraries used to integrate with popular frameworks can be found at Using OAuth 2.0 to Access Google APIs.

Refresh tokens

To maintain long-term access to Google APIs without requiring constant user re-authentication, your application must use a refresh token. For comprehensive implementation details, including the specific HTTP requests and parameters required, refer to the Google identity platform documentation.

To exchange a refresh token for an access token, make an HTTPS POST call to the Google OAuth 2.0 token endpoint. The following snippet shows an example request and response:

Request

curl -L -X POST 'https://oauth2.googleapis.com/token' \
-H 'Content-Type: application/x-www-form-urlencoded' \
-d 'client_id=client-id&client_secret=client-secret&refresh_token=refresh-token&grant_type=refresh_token'

Response

{
  "access_token": "access-token",
  "expires_in": 3599,
  "scope": "scope-list",
  "token_type": "Bearer",
  "refresh_token": "refresh-token",
  "refresh_token_expires_in": 112154
}

Token behavior during testing

Be aware of how refresh tokens behave depending on your Google Cloud project's publishing status:

  • Testing Mode: If your OAuth consent screen is configured with a "Testing" publishing status, the refresh tokens issued are time-based and expire after 7 days. During this period, you will receive a single refresh token that remains valid and usable for obtaining new access tokens until it reaches its expiration date.
  • Published Mode: Once your app is moved to "In Production" status, refresh tokens generally don't expire unless they are revoked or remain unused for a prolonged period (typically six months).

For a seamless user experience, ensure you publish your application before it is moved into a production environment to avoid 7-day token expirations.