Data Access and Authorization

The Google Health API utilizes a robust and standardized framework for managing user data access and security. A central component of this modernization is the transition from legacy Fitbit Authorization (FOT) to Google OAuth 2.0. This shift allows developers to leverage standard Google authentication libraries, simplifying implementation while providing users with a familiar and centralized interface for managing their permissions.

App Registration

All Google Health API apps must be registered using the Google Cloud console, which serves as a central hub for managing all of your Google apps.

For instructions on how to register your app, follow the steps at Getting Started. Here are the differences you'll notice when registering your apps.

Fitbit Web API Google Health API
Public link(s) https://dev.fitbit.com/apps https://console.cloud.google.com
Adding a new app Press Register a new app
  1. Create a Google Cloud Project
  2. Enable Google Health API
Basic Info Fields to complete:
  • Application Name
  • Description
  • Application Website URL
  • Organization
  • Organization Website URL
  • Terms of Service URL
  • Privacy Policy URL
 Fields to complete:
  • Application name
  • Support email
  • Audience (internal or external)
  • Contact email
  • Logo icon
  • Application website URL
  • Privacy policy URL
  • Terms of Service URL
  • Authorized Domain
Application Types A developer is required to select:
  • Server
  • Client
  • Personal
  • Web application
  • Android
  • Chrome Extension
  • iOS
  • TVs
  • Desktop app
  • Universal Windows platform
Client ID Registered when the application settings are saved Registered separately
Access Type Read and Write access is controlled at the app level Read and Write access is controlled at the scope level
Additional URLs
  • Redirect URL: Site where users are redirected to after the authorize the scopes
  • Authorized JavaScript Origins: HTTP origin that hosts the web application
  • Redirect URL: Site where users are redirected to after the authorize the scopes

OAuth Implementation

Google Health API apps only support the Google OAuth2 Client libraries. Client libraries are available for popular frameworks, which makes implementing OAuth 2.0 simpler. The differences between the Google OAuth2 libraries and the open source OAuth2 libraries are as follows:

Fitbit Web API Google Health API
OAuth2 library support Open Source Google OAuth2 Client libraries
Functionality Inconsistent across platforms Consistent across platforms
Authorization URL https://www.fitbit.com/oauth2/authorize https://accounts.google.com/o/oauth2/v2/auth
Token URL https://api.fitbit.com/oauth2/token https://oauth2.googleapis.com/token
Access Token Lifetime 8 hours 1 hour
Access Token Size 1024 bytes 2048 bytes
Refresh Token Refresh tokens are generated when using the Authorization Code Grant Flow. Only 1 refresh token can be generated for a user. Tokens never expire and can only be used once. To generate a refresh token, the authorization string must contain the query parameter "access_type=offline". Multiple refresh tokens can be created for a single user. Refresh tokens can be timed-based. They will expire if they have not been used in 6 months, the user granted time- based access, or the app is in "Testing" mode. See Refresh token expiration for more details.
Token Response JSON response contains:
  • access token
  • access token expiration
  • scopes
  • token type
  • refresh token
  • user ID
 JSON response contains:
  • access token
  • access token expiration
  • scopes
  • token type
  • refresh token

To obtain the user id, use the users.getIdentity endpoint.

Fitbit users must re-consent to your new integration, because your app is using a different OAuth library. It is not possible for access tokens and refresh tokens to be transferred to the Google Health API and work.