Google Health API

Junction’s default Google Health OAuth application is conditionally approved and available while Junction completes the required Cloud Application Security Assessment (CASA). Teams using Junction’s default application do not need to complete a separate assessment. Customers using their own OAuth application remain responsible for Google’s verification and CASA requirements.

Google Health API is the successor to the Fitbit Web API. It returns health and fitness data from Fitbit devices, Pixel Watches, and other sources synchronized to Google Health. This guide covers the google_health provider through Junction’s default application or an optional customer-owned application.

Connect with Junction’s default application

Connect users to Google Health through Junction Link in the same way as any other OAuth provider. Junction manages the OAuth application, callback, subscriber, and webhook infrastructure. You do not need to create a Google Cloud project, configure custom credentials, or complete the setup under Bring Your Own OAuth. Continue to Test authorization and data access after connecting a user.

Migrate from Fitbit

Google will turn down the legacy Fitbit Web API in September 2026, after which it will no longer synchronize Fitbit user data. This retirement applies to the legacy API, not Fitbit devices. Migrate existing fitbit connections to google_health before the shutdown to avoid an interruption. See Google’s retirement notice and migration guide.

Google Health uses Google OAuth 2.0, so every existing Fitbit user must authorize a new google_health connection. Fitbit access and refresh tokens cannot be transferred, and Link Bulk Import cannot convert a Fitbit grant into a Google Health grant.

Send new connections to Google Health

Offer google_health instead of fitbit to new users immediately.

Reconnect existing users

Reconnect the user to google_health with the same Junction user ID, using the Google Account linked to their Fitbit data.

Verify the new connection

Keep the existing Fitbit connection active until you receive the Google Health connection-created event, its historical pull completes, representative summary and timeseries resources contain data, and a new update webhook arrives.

Complete the cutover

Update provider filters, priorities, and downstream handling to use google_health, then deregister the Fitbit connection. Roll out in cohorts and follow up with users who dismiss or fail the new authorization flow.

During a dual-connection window, the same underlying Fitbit observations can arrive under both fitbit and google_health. Junction does not automatically deduplicate data across providers. Keep the overlap short and filter or deduplicate using provider filters and each resource’s source field in downstream processing.

Data parity with Fitbit

Google Health covers the primary Junction resources used by Fitbit integrations and adds several resources through its newer API surface.

Coverage	Junction resources
Shared coverage	Activity, body, sleep, sleep cycle, workouts, meals, profile, devices, heart rate, active calories, distance, steps, VO2 max, water, body temperature, fat, weight, heart rate variability, blood oxygen, respiratory rate, heart-rate alerts, and workout streams
Additional Google Health coverage	Floors-climbed timeseries, carbohydrates, caffeine, glucose, electrocardiogram summaries, and electrocardiogram voltage

This is resource-level parity, not a guarantee of identical fields or data availability. Granted scopes, device capabilities, recorded source data, and the user’s synchronization state determine which fields and resources are populated.

Configure Bring Your Own OAuth

Bring Your Own OAuth (BYOO) is available for the Grow and Scale plans.

Complete this setup separately for each Junction environment and region that uses your application.

Before you begin

You need:

A Google Cloud project administered by your organization
A Google account that is a Project Owner for that project
DNS access for a domain that your organization owns
Public application homepage, privacy policy, and terms of service pages
A customer-hosted HTTPS OAuth callback endpoint

Google’s OAuth policies require separate projects for testing and production. Unverified applications are limited to 100 users. While a project remains in Testing, only accounts listed under Google Auth Platform > Audience > Test users can authorize, and their refresh tokens expire after seven days. See Set up Google Cloud and OAuth.

Prepare the Junction environment

Open Config > Custom Credentials in the Junction Dashboard, select Google Health, and copy the preparation values displayed before the credential form. Alternatively, call Prepare team custom credentials with:

{
  "team_id": "<team-id>",
  "provider": "google_health"
}

Record both returned values:

Redirect URI: the Junction callback for the selected environment and region
IAM principal: the Junction service account that must impersonate your service account

For production, the returned Junction redirect URI is the target of your callback forwarder. It is not the redirect URI registered with Google, because your organization cannot verify ownership of a Junction domain.

Configure Google Cloud and OAuth

Create the Google Cloud project

Create or select the project, enable Google Health API, and record its project ID and numeric project number. Junction requires the project number, not the project ID.

Configure branding and policies

In Google Auth Platform > Branding, configure your application name, logo, support email, developer contacts, homepage, privacy policy, and terms of service.The public pages and an in-product disclosure shown immediately before consent must accurately explain how your application accesses, uses, stores, deletes, and shares Google Health data. Describe Junction as a service that receives and processes the data on your behalf. Your homepage or privacy policy must affirm that your use of Google Health information complies with the Google Health API data policy, including its Limited Use requirements.

Verify your domain

Using the Google Cloud Project Owner account, add the registrable root domain as a Domain property in Google Search Console, publish Google’s DNS TXT record, and verify ownership. Keep the TXT record in DNS, then add the root domain under Google Auth Platform > Branding > Authorized domains.Every domain used by your homepage, policy pages, JavaScript origins, or redirect URIs must be authorized and verifiable by your organization. Keep the list minimal: Google permits no more than ten authorized domains in a verification request.

Host the OAuth callback

Host an HTTPS callback on your verified domain, for example:

https://auth.example.com/oauth/callback/google_health

The endpoint must accept Google’s GET request, preserve the complete query string without parsing or re-encoding it, and return 307 Temporary Redirect to the Junction redirect URI returned by the preparation step.

GET /oauth/callback/google_health?code=abc123&state=xyz

HTTP/1.1 307 Temporary Redirect
Location: https://api.us.junction.com/v2/link/connect/google_health?code=abc123&state=xyz

Use the Junction target for the same environment and region. See Hosting OAuth Callbacks on Your Own Domain for all targets and implementation requirements.

Create the OAuth client

Create a Web application OAuth client. Google may call this option Web Server, including for native products that use Junction on their backend.Register your customer-hosted callback as the authorized redirect URI. Do not use Google’s https://www.google.com quick-start placeholder or the Junction callback directly. Save the OAuth client ID and client secret securely.

Add the scopes

In Google Auth Platform > Data Access, add every scope requested by your Junction flow. Without custom team scope requirements, Junction requests all of these supported read-only scopes:

Junction data	Google OAuth scope
Identity	`openid`, `email`
Activity, workouts, steps, distance, and VO2 max	`https://www.googleapis.com/auth/googlehealth.activity_and_fitness.readonly`
Sleep	`https://www.googleapis.com/auth/googlehealth.sleep.readonly`
Heart rate, body measurements, glucose, oxygen, and temperature	`https://www.googleapis.com/auth/googlehealth.health_metrics_and_measurements.readonly`
Meals, water, caffeine, and carbohydrates	`https://www.googleapis.com/auth/googlehealth.nutrition.readonly`
Electrocardiogram	`https://www.googleapis.com/auth/googlehealth.ecg.readonly`
Irregular rhythm notifications	`https://www.googleapis.com/auth/googlehealth.irn.readonly`
Workout location	`https://www.googleapis.com/auth/googlehealth.location.readonly`
Profile	`https://www.googleapis.com/auth/googlehealth.profile.readonly`
Paired devices and settings	`https://www.googleapis.com/auth/googlehealth.settings.readonly`

Junction currently requests and uses only the read-only scopes listed above, so do not request Google Health write scopes. If your product does not use every resource, configure team scope requirements before testing so the consent flow requests only the scopes you can justify. Google requires a justification and an in-product demonstration for every restricted scope requested. See the Google Health scope reference.

Configure the service account and IAM

Create a service account in the Google Health project. Junction uses it only to manage the Google Health subscriber and user subscriptions; end-user health data still requires user OAuth consent. Grant the service account Google Health API Editor (roles/health.editor) on the project. Then grant the Junction IAM principal returned by the preparation step Service Account Token Creator (roles/iam.serviceAccountTokenCreator) on that service account. You can configure both grants in Google Cloud Console or with gcloud:

gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="serviceAccount:SERVICE_ACCOUNT_EMAIL" \
  --role="roles/health.editor"

gcloud iam service-accounts add-iam-policy-binding SERVICE_ACCOUNT_EMAIL \
  --project=PROJECT_ID \
  --member="serviceAccount:JUNCTION_IAM_PRINCIPAL" \
  --role="roles/iam.serviceAccountTokenCreator"

Replace the uppercase placeholders with your project ID, service account email, and the exact environment-specific Junction principal. Do not create or upload a service-account JSON key.

Add the credentials to Junction

In Config > Custom Credentials > Google Health, enter:

OAuth Client ID
OAuth Client Secret
Redirect URL Override: your customer-hosted callback URL
Project Number: the numeric Google Cloud project number
Service Account Email

The credential form is shared with providers that can use a Junction-owned redirect URI, so Redirect URL Override is optional for those providers. Google requires production redirect URI domains to be owned and verified by the OAuth application developer, so set this field to your customer-hosted callback URL for Google Health. To configure the credentials through the Org Management API, call Set team custom credentials:

{
  "team_id": "<team-id>",
  "provider": "google_health",
  "client_id": "<oauth-client-id>",
  "client_secret": "<oauth-client-secret>",
  "redirect_url_override": "https://auth.example.com/oauth/callback/google_health",
  "details": {
    "project_number": "123456789012",
    "service_account_email": "google-health@project.iam.gserviceaccount.com"
  }
}

Saving valid credentials activates the provider immediately. Junction creates and manages the Google Health subscriber, subscription IDs, webhook endpoint, and verification secret. Do not configure separate Google Health webhook infrastructure.

Test authorization and data access

Prepare a test user

If you use a customer-owned application in Testing, add the Google account under Google Auth Platform > Audience > Test users. Ensure the account has representative Fitbit or Pixel Watch data and has recently synchronized with Google Health.

Complete authorization

Use Junction Link to connect google_health. Confirm that the callback returns to Junction, the consent screen contains the expected scopes, and the connection-created event is delivered.

Verify ingestion

Confirm the connection through Get user’s connected providers, inspect available resources through user resources, and monitor historical pulls. Google Health backfills up to 90 days of available data.

Read and update data

Read at least one populated resource through the Data Access API, such as Activity Summary or Steps. Then synchronize new source data and confirm that Junction delivers the corresponding update webhook.

Common failures are:

Symptom	Check
`redirect_uri_mismatch`	For a customer-owned application, Google, Junction’s Redirect URL Override, and the authorization request must use the exact same customer callback URL.
User cannot authorize	For a customer-owned application in Testing, add the account as a test user and confirm the application’s publishing status.
Custom credentials fail to save	Check the project number, service account email, and both IAM grants.
A resource is absent	Confirm that its scope was granted, source data exists, and the historical pull has completed.

Verify a customer-owned application

Record the verification video

Use the OAuth client intended for production, along with the branding, callback, and application that you will submit. The client can remain in Testing while you record with an allowlisted test user. Record the complete customer-facing flow:

Start the Google Health connection from your application and complete the end-to-end OAuth grant flow, including Junction Link.
Show the same application name and branding as your submission.
Set the consent screen language to English, then show the complete screen with every requested scope and the browser address bar containing the submitted OAuth client ID.
Return to your application and demonstrate the user-facing functionality enabled by each requested scope.
If your application uses multiple OAuth clients, show how it accesses data through each client.

A successful callback or API response alone does not demonstrate how your product uses the data. Use a test account and safe sample data. Do not expose client secrets, API keys, access tokens, or unrelated personal data. Upload the recording to YouTube Studio with Unlisted visibility, then provide the link in Google’s verification form. See Google’s restricted-scope verification requirements for the current recording requirements.

Submit the production application

Before submitting, confirm that your production application:

Uses only the scopes its user-facing features require
Has verified domains and consistent branding, homepage, privacy policy, and terms URLs
Provides an accurate in-product disclosure and data deletion path
Has working reviewer credentials or test instructions
Uses the production customer-owned callback and Junction credentials

In the Google Cloud OAuth Verification Center, declare every scope, provide a scope-by-scope justification, add relevant product documentation, include reviewer instructions, and provide the unlisted YouTube demonstration-video link. Google Health scopes are restricted. Because Junction receives and processes this data through its servers, your application must complete an annual third-party security assessment under CASA in addition to OAuth verification. Google Trust and Safety will provide the assessment instructions. Review Google Health app verification and restricted-scope verification before submitting. Follow the current Verification Center prompts for publishing status. Before public launch, the final application must be verified and In Production.

Bring Your Own OAuth

Junction iOS App

Providers

Connecting Providers

Device Data

Mobile SDKs

Provider Guides

Google Health API

Connect with Junction’s default application

Migrate from Fitbit

Data parity with Fitbit

Configure Bring Your Own OAuth

Before you begin

Prepare the Junction environment

Configure Google Cloud and OAuth

Configure the service account and IAM

Add the credentials to Junction

Test authorization and data access

Verify a customer-owned application

Record the verification video

Submit the production application

​Connect with Junction’s default application

​Migrate from Fitbit

​Data parity with Fitbit

​Configure Bring Your Own OAuth

​Before you begin

​Prepare the Junction environment

​Configure Google Cloud and OAuth

​Configure the service account and IAM

​Add the credentials to Junction

​Test authorization and data access

​Verify a customer-owned application

​Record the verification video

​Submit the production application

Connect with Junction’s default application

Migrate from Fitbit

Data parity with Fitbit

Configure Bring Your Own OAuth

Before you begin

Prepare the Junction environment

Configure Google Cloud and OAuth

Configure the service account and IAM

Add the credentials to Junction

Test authorization and data access

Verify a customer-owned application

Record the verification video

Submit the production application