# How to Integrate Retool with Google Fit

- Tool: Retool
- Difficulty: Intermediate
- Time required: 30 minutes
- Last updated: April 2026

## TL;DR

The Google Fit REST API was officially deprecated in 2024 in favor of Health Connect. Connect Retool to Google Fit's Fitness REST API using a REST API Resource with Google OAuth for existing data access while it remains available, or transition to Health Connect API for ongoing fitness data integration. Retool can build fitness analytics dashboards from aggregated step counts, activity sessions, and health metrics exported from either platform.

## Why connect Retool to Google Fit — and what to know about its deprecation?

Google announced the deprecation of the Google Fit REST API and Android SDK in 2024, with migration paths pointing to Android Health Connect as the replacement. For teams with existing Google Fit integrations, the REST API continues to work for accessing historical data from users who have consented via OAuth. For new implementations, Health Connect is the recommended path. This guide covers both: accessing existing Google Fit data via the Fitness REST API and planning the transition to Health Connect.

Practical Retool use cases for Google Fit data include wellness program dashboards for HR teams tracking aggregate (anonymized) activity metrics across opt-in employee participants, fitness app admin panels for products that write data to Google Fit and need internal visibility into user engagement, and research data collection tools that aggregate fitness metrics with participant consent for health studies. All of these require user OAuth consent — Retool cannot access Google Fit data without explicit user authorization.

The Fitness REST API uses a data source model where each data type (steps, calories, heart rate) has a unique data source ID, and historical data is accessed through dataset aggregation queries with time range parameters. The API returns data in a nested JSON structure with buckets, datasets, and points. JavaScript transformers in Retool are essential for reshaping this structure into flat arrays that Table and Chart components can consume directly. Understanding the API's data model is the most important prerequisite for building useful Retool integrations.

## Before you start

- A Google account with Google Fit app installed and fitness data collected on an Android or Wear OS device
- Google Fitness API enabled in Google Cloud Console (note: the API is deprecated — enable it while it remains accessible)
- OAuth 2.0 credentials with the fitness.activity.read and fitness.body.read scopes configured on the consent screen
- A Retool account with Resource creation permissions
- Awareness that this API is deprecated — for new production integrations, evaluate Health Connect as the migration target

## Step-by-step guide

### 1. Enable Fitness API and configure OAuth scopes

Navigate to Google Cloud Console → APIs & Services → Library and search for Fitness API. Click it and press Enable. Note the deprecation banner — the API remains functional for existing integrations. In APIs & Services → Credentials, click Create Credentials → OAuth client ID, set the application type to Web application, and add Retool's OAuth callback URL: https://oauth.retool.com/oauth/user/oauthcallback (or your self-hosted instance's callback URL) to the Authorized redirect URIs. Copy the Client ID and Client Secret. Next, go to APIs & Services → OAuth consent screen. Set User Type to External if you are accessing data from user accounts outside your Google Workspace, or Internal for Workspace-only deployments. Add the required Google Fit scopes: https://www.googleapis.com/auth/fitness.activity.read for step counts and activity sessions, https://www.googleapis.com/auth/fitness.body.read for body metrics like weight and heart rate, and https://www.googleapis.com/auth/fitness.location.read for GPS and distance data if needed. For External user type, the OAuth consent screen requires app verification by Google if you want to access data from users outside your organization — for internal wellness programs using Workspace accounts, Internal type avoids this requirement. Save the consent screen configuration and proceed to create the Retool resource.

**Expected result:** The Fitness API is enabled in your Google Cloud project, OAuth credentials are created, and the consent screen is configured with the appropriate fitness data scopes.

### 2. Create the Google Fit REST API Resource in Retool

Navigate to the Resources tab in Retool and click Add Resource → REST API. Name the resource Google Fit API. Set the Base URL to https://www.googleapis.com/fitness/v1/users/me. In the Authentication section, select OAuth 2.0. Fill in the OAuth fields: Authorization URL as https://accounts.google.com/o/oauth2/auth, Token URL as https://oauth2.googleapis.com/token, enter your Client ID and Client Secret, and set the Scope field to the fitness scopes you configured separated by spaces (e.g., https://www.googleapis.com/auth/fitness.activity.read https://www.googleapis.com/auth/fitness.body.read). In the additional OAuth parameters section, add access_type: offline to receive a refresh token that allows long-lived access without requiring users to re-authorize every hour. Save the resource and click Connect — Retool opens the Google OAuth flow in a popup. Sign in with a Google account that has Google Fit data and accept the permissions. After authorization, the resource shows as Connected. For internal wellness programs where you need to access multiple user accounts, each user must authorize individually — consider using Retool's per-user OAuth option rather than sharing credentials. The server-side proxy ensures credentials are never exposed to the browser.

**Expected result:** The Google Fit REST API Resource is configured and Connected in Retool, with OAuth authentication successfully established and the base URL pointing to the Fitness API user endpoint.

### 3. Query aggregated fitness data with dataset:aggregate

Create a new query in the Code panel. Select the Google Fit API resource. Set the HTTP method to POST and the path to /dataset:aggregate. The aggregate endpoint accepts a JSON body specifying the data type, time range, and bucket size. Set the body type to JSON. The request body requires: aggregateBy (array of data source types), bucketByTime (time bucket configuration with durationMillis for daily or weekly groupings), and startTimeMillis and endTimeMillis (Unix timestamps in milliseconds). To get daily step counts for the last 7 days: set startTimeMillis to 7 days ago in milliseconds, endTimeMillis to now, bucketByTime.durationMillis to 86400000 (24 hours in milliseconds), and aggregate by com.google.step_count.delta. Click Run. The response contains a bucket array where each bucket corresponds to one day, containing a dataset array with a point array of step count values for that day. Create a JavaScript transformer to flatten this nested structure into a simple array of date and step count pairs for Chart and Table binding. This is the most commonly needed query for any fitness dashboard.

```
// POST body for Google Fit dataset:aggregate
// Returns daily step counts for the last 7 days
const now = Date.now();
const sevenDaysAgo = now - (7 * 24 * 60 * 60 * 1000);

// Use this as the query body (JSON type)
const requestBody = {
  "aggregateBy": [{
    "dataTypeName": "com.google.step_count.delta"
  }],
  "bucketByTime": {
    "durationMillis": 86400000
  },
  "startTimeMillis": sevenDaysAgo,
  "endTimeMillis": now
};

// Transformer to flatten the response
const buckets = data.bucket || [];
return buckets.map(bucket => {
  const date = new Date(parseInt(bucket.startTimeMillis));
  let steps = 0;
  if (bucket.dataset && bucket.dataset[0] && bucket.dataset[0].point) {
    bucket.dataset[0].point.forEach(point => {
      if (point.value && point.value[0]) {
        steps += point.value[0].intVal || 0;
      }
    });
  }
  return {
    date: date.toLocaleDateString('en-US', { month: 'short', day: 'numeric' }),
    date_full: date.toISOString().split('T')[0],
    steps: steps,
    goal_met: steps >= 10000
  };
});
```

**Expected result:** The aggregate query returns daily step count data and the transformer produces a clean array with date and steps fields ready to bind to a Bar Chart showing step counts per day.

### 4. List activity sessions and build the dashboard

Create a second query to list activity sessions. Set the HTTP method to GET and the path to /sessions. Add query parameters: startTime as an RFC3339 timestamp (e.g., {{ new Date(Date.now() - 30*24*60*60*1000).toISOString() }}) and endTime as {{ new Date().toISOString() }}. The sessions endpoint returns an array of session objects with fields including name, description, activityType, startTimeMillis, endTimeMillis, and application. Activity types are numeric codes — 7 is walking, 8 is running, 1 is biking, 72 is sleep. Create a transformer that converts activity type codes to human-readable labels and calculates session durations in minutes. Drag a Table onto the canvas and bind it to {{ listSessions.data }}. For the main dashboard layout, place the steps Chart at the top (binding to the aggregate query data), a Stat component showing total steps for the week, and the activity sessions Table below. Add a DateRangePicker that drives both queries. Label the dashboard clearly with an API Deprecation Notice Container explaining that Google Fit API is deprecated and linking to Health Connect migration docs — this is helpful for any team member inheriting the Retool app and wondering about its long-term viability.

```
// Transformer for activity sessions list
const activityTypes = {
  1: 'Biking', 7: 'Walking', 8: 'Running', 9: 'Running (treadmill)',
  10: 'In vehicle', 11: 'Elliptical', 13: 'In vehicle', 15: 'On foot',
  16: 'Still (not moving)', 17: 'Unknown activity', 22: 'Jumping rope',
  57: 'Meditation', 72: 'Sleep', 74: 'Snowboarding', 83: 'Strength training',
  84: 'Weightlifting', 93: 'Yoga'
};

const sessions = data.session || [];
return sessions.map(s => {
  const start = new Date(parseInt(s.startTimeMillis));
  const end = new Date(parseInt(s.endTimeMillis));
  const durationMin = Math.round((end - start) / 60000);
  return {
    name: s.name || 'Unnamed session',
    activity: activityTypes[s.activityType] || `Activity ${s.activityType}`,
    date: start.toLocaleDateString(),
    start_time: start.toLocaleTimeString([], { hour: '2-digit', minute: '2-digit' }),
    duration_min: durationMin,
    app: s.application?.packageName || 'Unknown'
  };
}).sort((a, b) => new Date(b.date) - new Date(a.date));
```

**Expected result:** A complete fitness dashboard shows a bar chart of daily step counts, stat components for weekly totals, and a table of recent activity sessions with human-readable activity types and durations.

## Best practices

- Note that the Google Fit REST API is deprecated — treat this integration as maintenance mode for existing implementations and plan migration to Health Connect for new fitness data collection requirements.
- Always display data in aggregate form (daily totals, weekly averages) rather than individual step-by-step data points — this is both more useful for dashboards and more privacy-respecting for wellness programs.
- Request only the minimum required OAuth scopes for your use case — fitness.activity.read alone is sufficient for step counts and sessions, avoiding the need for Google app verification for narrow use cases.
- Store the transformer for flattening Google Fit's bucket/dataset/point response structure as a reusable JavaScript utility in your Retool app — every query type needs the same flattening logic.
- Add a DateRangePicker to control the startTimeMillis and endTimeMillis parameters in aggregate queries — hardcoded time ranges require code changes to view different periods.
- For multi-user wellness programs, use Retool's per-user OAuth option (rather than shared credentials) so each employee authenticates individually — this maintains proper data access boundaries.
- Cache aggregate queries for at least 30 minutes — fitness data is written by devices on a delay and does not change rapidly enough to justify frequent API calls.

## Use cases

### Employee wellness program analytics dashboard

Build an opt-in wellness program tracker for HR teams that aggregates daily step counts and activity minutes across consenting employees. Each employee authorizes Google Fit OAuth once, and their aggregate metrics appear in a Retool dashboard showing daily and weekly averages, goal achievement rates, and trend charts. Individual data is anonymized in the display — only aggregate team statistics appear, with appropriate privacy controls configured in Retool's permission system.

Prompt example:

```
Build a Retool dashboard that queries the Google Fit API for daily step totals for the current week using the dataset:aggregate endpoint, displays the data in a Chart showing daily steps as a bar chart with a 10,000-step goal line, and shows a Table with weekly totals and goal achievement percentage. Include a date range picker to view historical periods.
```

### Fitness app activity session browser

Create an internal tool for a fitness app company's support and product team to browse user activity sessions from Google Fit — workout types, durations, calorie estimates, and timestamps — for debugging and product analytics. A Select component lets the team choose a test user account (with proper consent), and the activity session list shows all recorded workouts with their data sources. This helps the support team diagnose sync issues between the app and Google Fit.

Prompt example:

```
Build a Retool app where support staff can select a test user's Google account (with pre-authorized OAuth), view a Table of their activity sessions from the Google Fit API including activity type, start time, end time, duration, and calorie data, and click a row to see the detailed data points for that session.
```

### Health data export and research aggregation tool

Build a research data collection dashboard where study participants can authorize Google Fit access and researchers can pull aggregated health metrics (steps, heart rate, sleep) with consent. The Retool app lists consented participants, shows their metric availability by data type, and exports time-series data to a connected PostgreSQL database for statistical analysis. A summary Table shows average metrics across the participant cohort by age group or other demographic segments stored in the database.

Prompt example:

```
Build a Retool research tool that queries Google Fit for a consented participant's daily step and heart rate data for the last 30 days, stores it in a PostgreSQL database via an upsert query, and displays a cohort comparison Table showing average steps and resting heart rate by demographic segment pulled from the database.
```

## Troubleshooting

### OAuth authorization fails with 'Access blocked: app has not completed Google verification'

Cause: The Google Fitness API scopes are classified as sensitive or restricted, requiring Google to verify the app before External users can authorize it.

Solution: For Internal Google Workspace deployments, change the OAuth consent screen User Type to Internal — this bypasses the verification requirement for users within your organization. For External users, you can add specific test user emails in the OAuth consent screen's Test users section (up to 100 test users) to grant them access during development. For production access to non-Workspace users, submit the app for Google verification.

### dataset:aggregate returns empty bucket arrays with no data points

Cause: The user has Google Fit installed but no data has been synced to the cloud, the OAuth token does not have the correct fitness scope for the requested data type, or the time range specified in the request has no recorded data.

Solution: Verify the user has recorded fitness data in the Google Fit app that covers the requested time range. Check the OAuth scope matches the data type requested — step counts require fitness.activity.read, while body metrics require fitness.body.read. Try a wider time range (30 days) to confirm data exists. In the aggregate request, confirm the dataTypeName matches exactly: com.google.step_count.delta (not step_count alone).

### API returns 403 with 'Fitness API deprecated' or features stop working

Cause: Google has disabled parts of the Fitness API as part of its deprecation process. The full deprecation timeline was announced in 2024.

Solution: Check Google's official Health Connect migration guide at developer.android.com/health-and-fitness/guides/health-connect/migrate. For read access to historical data, the Fitness REST API may still function with existing authorized tokens. For new integrations collecting data from users, implement Health Connect API support in your Android app and use Health Connect's data export capabilities to feed your Retool dashboard via BigQuery or a custom backend.

## Frequently asked questions

### Is the Google Fit API actually shut down and can I still use it?

Google announced the deprecation of the Google Fit REST API in 2024, directing developers to migrate to Health Connect. As of the announcement, the API continues to function for existing integrations with user OAuth consent — data can still be read from users who previously authorized access. However, new features will not be added, and the API may be fully shut down in the future. Check Google's official developer blog for the current status and shutdown timeline before building new integrations that depend on it.

### Can Retool write fitness data back to Google Fit?

Yes, the Google Fit REST API supports write operations via the datasets endpoint (POST to create datasets) using the fitness.activity.write scope. However, writing data from Retool back to Google Fit is an unusual use case since Retool is an internal tool builder — fitness data is typically written by user apps, not internal operations tools. For reading and analyzing fitness data, the read-only scopes are sufficient and carry fewer OAuth scope approval requirements.

### How do I handle multiple users with different Google Fit accounts in one Retool app?

Use Retool's per-user OAuth configuration for the Google Fit Resource (disable Share OAuth 2.0 credentials between users). Each Retool user authenticates with their own Google account and can only access their own Fit data. For wellness programs where an admin needs to view aggregate data across multiple users, each user must individually authorize and their data should be stored in your own database (with appropriate consent and privacy controls) rather than queried directly from Google Fit at report time.

### What is Health Connect and how does it relate to a Retool integration?

Health Connect is Google's replacement for Google Fit as the central health data repository on Android. Unlike Google Fit's cloud REST API, Health Connect is primarily an on-device API (Android SDK). For cloud access to Health Connect data in a Retool integration, users need to sync their Health Connect data to a backend through an app or Health Connect's cloud sync feature. If your Android app writes to Health Connect, you would build a backend endpoint that reads from Health Connect's cloud sync and exposes it to Retool — rather than querying Health Connect directly from Retool.

---

Source: https://www.rapidevelopers.com/retool-integrations/google-fit
© RapidDev — https://www.rapidevelopers.com/retool-integrations/google-fit