# How to Integrate Retool with Garmin Connect

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

## TL;DR

Connecting Retool to Garmin Connect requires access to Garmin's Health API, which is a partner program requiring approval — not a self-service developer API. Once approved, you configure a REST API Resource with OAuth 1.0a credentials and build fitness data dashboards. For corporate wellness programs, this enables activity, sleep, and heart rate dashboards from Garmin wearables.

## Build a Garmin Fitness Data Dashboard in Retool

Garmin Connect is the ecosystem for Garmin's fitness wearables — the Fenix, Forerunner, Vivosmart, and other devices used by athletes and corporate wellness programs worldwide. Unlike consumer-focused APIs, Garmin's Connect API is not self-service. Access requires applying to Garmin's Health API partner program, which evaluates your use case, data privacy practices, and business justification before granting API credentials.

Once approved, Garmin's Health API uses OAuth 1.0a — an older, more complex authentication protocol than OAuth 2.0. Each request must be cryptographically signed using your consumer key and secret plus the user's access token and token secret. Retool's REST API Resource can be configured to handle OAuth 1.0a through custom authentication headers or a pre-signing proxy.

The typical use case for a Retool Garmin integration is a corporate wellness dashboard: an HR or wellness program coordinator needs to view aggregated activity data, step counts, sleep scores, and stress levels for enrolled employees — without accessing individual-level data that would violate privacy policies. Garmin's Daily Summaries endpoint provides the data for this, and Retool's Table and Chart components make it easy to visualize trends over time.

## Before you start

- Approved access to Garmin's Health API partner program — apply at https://developer.garmin.com/health-api/overview/
- Garmin Health API consumer key and consumer secret from the Garmin Developer Portal
- OAuth 1.0a access tokens for each Garmin Connect user whose data you'll access
- A Retool account (Cloud or self-hosted) with permission to create Resources
- Understanding of OAuth 1.0a request signing or access to a pre-signing proxy service

## Step-by-step guide

### 1. Apply for Garmin Health API access

Garmin's Health API is not a self-service developer API. You must apply for access through Garmin's partner program before you can make any API calls. This is a fundamental difference from APIs like Fitbit, Withings, or Strava.

Navigate to https://developer.garmin.com/health-api/overview/ and read the documentation. Click 'Request API Access' or navigate to the developer portal at https://developer.garmin.com. Create a developer account and submit a partner application.

The application asks for:
- Your organization name and contact information
- A description of your use case and the application you're building
- Information about data privacy practices and how you'll protect user data
- Expected number of users
- Business model and how the integration creates value

Approval timelines vary — typically 2-4 weeks. Garmin evaluates whether your use case aligns with their health data ethics guidelines. Healthcare, corporate wellness, coaching platforms, and research applications are commonly approved.

Once approved, you receive a consumer key and consumer secret via the developer portal. These are permanent credentials for your application (not user-specific). User-specific access tokens are obtained later through the OAuth 1.0a flow.

For testing before approval, Garmin provides a sandbox environment with mock data. Ask about sandbox access when submitting your application.

**Expected result:** You have received Garmin Health API approval and have your consumer key and consumer secret from the developer portal.

### 2. Understand OAuth 1.0a and obtain user access tokens

OAuth 1.0a is more complex than OAuth 2.0. Each API request must be signed using a cryptographic signature combining your consumer key, consumer secret, user access token, user token secret, a timestamp, and a nonce. The signature process is prescribed by the OAuth 1.0a spec and cannot be simplified.

The OAuth 1.0a flow for Garmin:
1. Your application requests a temporary request token from Garmin's OAuth endpoint
2. Your application redirects the user to Garmin's authorization URL with the request token
3. The user approves access in Garmin Connect
4. Garmin redirects back to your callback URL with an oauth_verifier
5. Your application exchanges the request token + verifier for a permanent access token

For Retool, you have two options:

Option A (simpler): Use a separate OAuth 1.0a signing service. A small server-side script (Node.js or Python) handles the OAuth signing and exposes a simple Bearer token endpoint that your Retool REST API Resource calls. The signing service adds the OAuth Authorization header before forwarding to Garmin.

Option B (Retool Custom Auth): Configure Retool's Custom Auth with a JavaScript function that builds the OAuth 1.0a Authorization header signature. This is feasible but complex — the signature requires HMAC-SHA1 hashing with specific string formatting.

For most teams, Option A (a signing proxy) is more reliable and maintainable. Once implemented, your Retool resource calls the proxy with a simple Bearer token, and the proxy handles OAuth 1.0a signing.

```
// OAuth 1.0a Authorization header format (for reference)
// The header value looks like:
// OAuth realm="",
//   oauth_consumer_key="your_consumer_key",
//   oauth_nonce="random_string",
//   oauth_signature="base64_hmac_sha1_signature",
//   oauth_signature_method="HMAC-SHA1",
//   oauth_timestamp="unix_timestamp",
//   oauth_token="user_access_token",
//   oauth_version="1.0"

// The signature base string is:
// HTTP_METHOD&url_encoded(base_url)&url_encoded(sorted_params_string)
// Signed with HMAC-SHA1 key: url_encode(consumer_secret)&url_encode(token_secret)
```

**Expected result:** You have a method for obtaining and using OAuth 1.0a access tokens for Garmin API requests, either via a signing proxy or Retool Custom Auth.

### 3. Create the Garmin REST API Resource in Retool

With OAuth 1.0a authentication handled (either via a signing proxy or Custom Auth), create the Garmin REST API Resource in Retool.

For the signing proxy approach:
Name: Garmin API Proxy
Base URL: https://your-signing-proxy.example.com/garmin
Authentication: Bearer token (the proxy's API key)

For direct Garmin API with Custom Auth:
Name: Garmin Health API
Base URL: https://healthapi.garmin.com/wellness-api/rest
Authentication: Custom Auth

Garmin's Health API base URL is https://healthapi.garmin.com/wellness-api/rest. All endpoints are relative to this base.

For the Custom Auth approach, configure the auth steps in Retool's resource Custom Auth section:
1. Build the OAuth 1.0a Authorization header using a JavaScript step that computes the HMAC-SHA1 signature
2. Store the header value in a variable
3. Set the Authorization header for all requests using the variable

The custom auth needs your consumer key, consumer secret, user access token, and token secret — store these in Retool Configuration Variables marked as secrets.

Test the resource with GET /dailies?uploadStartTimeInSeconds={timestamp}&uploadEndTimeInSeconds={timestamp}.

```
// Garmin Health API endpoint overview:
// Base URL: https://healthapi.garmin.com/wellness-api/rest
//
// Key endpoints:
// GET /dailies - Daily activity summaries
// GET /activities - Detailed activity data
// GET /sleeps - Sleep tracking data  
// GET /body-composition - Weight, BMI data
// GET /stress - Stress level data
// GET /heart-rate-variability - HRV summaries
// GET /respiration - Breathing rate data
// GET /user-metrics - User fitness metrics
//
// All endpoints accept uploadStartTimeInSeconds and uploadEndTimeInSeconds
// as Unix epoch timestamps for date range filtering
```

**Expected result:** The Garmin REST API Resource is created in Retool and a test query to /dailies returns daily activity summary data.

### 4. Query daily activity summaries and sleep data

Create a getDailySummaries query. Set method to GET and path to /dailies. Garmin uses Unix epoch timestamps for date range filtering — add these query parameters:
- uploadStartTimeInSeconds: {{ Math.floor(new Date(datePicker_start.value).getTime() / 1000) }}
- uploadEndTimeInSeconds: {{ Math.floor(new Date(datePicker_end.value).getTime() / 1000) }}

The response includes a dailies array. Each record has: calendarDate, steps, distanceInMeters, activeTimeInSeconds, floorsClimbed, averageHeartRateInBeatsPerMinute, maxHeartRateInBeatsPerMinute, bodyBatteryDynamicFeedbackEvent, and more.

For sleep data, create a getSleepData query: GET /sleeps with the same timestamp parameters. The response includes sleepTimeInSeconds, deepSleepDurationInSeconds, lightSleepDurationInSeconds, remSleepInSeconds, and sleepScores.

For stress data: GET /stress with timestamp parameters. Returns stressLevel (0-100) and bodyBattery readings.

Create transformers for each data type that convert Unix timestamps to readable dates, convert seconds to hours/minutes, and format distance from meters to kilometers or miles.

```
// Transformer for Garmin daily summaries
const dailies = data.dailies || [];
return dailies.map(day => ({
  date: day.calendarDate,
  steps: day.steps || 0,
  distance_km: day.distanceInMeters ? (day.distanceInMeters / 1000).toFixed(2) : '0',
  active_minutes: day.activeTimeInSeconds ? Math.round(day.activeTimeInSeconds / 60) : 0,
  floors: day.floorsClimbed || 0,
  calories: day.activeKilocalories || 0,
  avg_heart_rate: day.averageHeartRateInBeatsPerMinute || 0,
  max_heart_rate: day.maxHeartRateInBeatsPerMinute || 0,
  body_battery_low: day.minBodyBattery || null,
  body_battery_high: day.maxBodyBattery || null,
  stress_avg: day.averageStressLevel || null
}));
```

**Expected result:** The getDailySummaries and getSleepData queries return daily fitness metrics for the selected date range, formatted for display in Retool Tables and Charts.

### 5. Build the wellness dashboard UI

Create a dashboard layout with three sections:

Top row: Stat components for key weekly metrics:
- Average Daily Steps (compare to 10,000 goal)
- Average Sleep Hours
- Average Stress Level
- Total Active Minutes

Middle section: Line Chart showing step count per day over the selected date range. Configure the Chart component with:
- X-axis: date field
- Y-axis: steps field
- Type: Line + Area for visual fill
- Reference line at 10,000 (goal line)

Bottom section: A 2-column layout. Left: A Table of daily summaries with all metrics. Right: A stacked bar chart showing sleep composition (deep, light, REM, awake) per night.

For corporate wellness use, add a User ID dropdown at the top that selects which enrolled user's data to view (loaded from a database Resource containing your enrolled users list). When the user dropdown changes, all Garmin queries re-run with the new user's access token — this requires storing access tokens per user in your database and parameterizing the auth configuration.

Add a Date Range picker (defaulting to the last 30 days) that drives the timestamp parameters in all queries.

```
// Transformer for sleep chart data
const sleeps = data.sleeps || [];
return sleeps.map(night => ({
  date: night.calendarDate,
  total_hours: night.sleepTimeInSeconds ? (night.sleepTimeInSeconds / 3600).toFixed(1) : 0,
  deep_hours: night.deepSleepDurationInSeconds ? (night.deepSleepDurationInSeconds / 3600).toFixed(1) : 0,
  light_hours: night.lightSleepDurationInSeconds ? (night.lightSleepDurationInSeconds / 3600).toFixed(1) : 0,
  rem_hours: night.remSleepInSeconds ? (night.remSleepInSeconds / 3600).toFixed(1) : 0,
  awake_hours: night.awakeDurationInSeconds ? (night.awakeDurationInSeconds / 3600).toFixed(1) : 0,
  sleep_score: night.sleepScores?.overall?.value || null
}));
```

**Expected result:** A complete wellness dashboard showing step trends, sleep composition, and stress metrics. The date range picker updates all charts dynamically.

### 6. Handle multi-user data and access token management

For corporate wellness programs with multiple enrolled users, you need to manage OAuth 1.0a access tokens per user. Each user's access token pair (access_token and token_secret) must be stored securely.

Store user tokens in a database resource connected to Retool (your PostgreSQL or another database). Create a users_garmin_tokens table with: user_id, garmin_access_token, garmin_token_secret, enrolled_at.

When a Retool user selects a specific employee from the user dropdown, fetch their tokens from the database and parameterize the Garmin API calls with those tokens.

For the OAuth 1.0a signing with per-user tokens, update your signing proxy to accept user_id and look up the appropriate tokens from your database, or pass the token and token_secret to the proxy in the request.

For new user enrollment, implement the OAuth 1.0a flow (Steps 1-5 described earlier) in a Retool Workflow or a separate enrollment web page. Store the resulting access tokens in your users_garmin_tokens table.

For compliance with GDPR and corporate wellness data regulations, implement data deletion: when a user unenrolls from the wellness program, delete their Garmin tokens from the database and revoke OAuth access at Garmin's token revocation endpoint.

For complex multi-user wellness program integrations involving token lifecycle management and privacy compliance, RapidDev's team can help architect the full solution.

```
-- SQL query to fetch user's Garmin tokens
-- Use this in a Retool database Resource query
SELECT 
  u.id,
  u.display_name,
  u.department,
  gt.garmin_access_token,
  gt.garmin_token_secret,
  gt.enrolled_at
FROM users u
JOIN users_garmin_tokens gt ON u.id = gt.user_id
WHERE u.id = {{ select_user.value }}
  AND gt.revoked_at IS NULL
LIMIT 1;
```

**Expected result:** Multi-user support works: selecting a different user loads their Garmin data. Tokens are stored securely in the database and the dashboard respects user-level data access.

## Best practices

- Store all OAuth credentials (consumer key, consumer secret, user access tokens) in Retool Configuration Variables marked as secrets or in an encrypted database column — never in resource headers or code.
- Use a signing proxy to handle OAuth 1.0a complexity — this keeps the cryptographic signing code isolated and makes the Retool resource configuration simple.
- Query Garmin's API with rolling time windows (e.g., last 24 hours uploaded) on a schedule via Retool Workflows rather than on-demand large date ranges — Garmin recommends this pattern for production integrations.
- For corporate wellness programs, always aggregate data to team/cohort level rather than displaying individual records in dashboards — this protects employee privacy and typically satisfies regulatory requirements.
- Implement OAuth token revocation when users unenroll from your program — call Garmin's token revocation endpoint and delete tokens from your database.
- Handle the case where Garmin devices haven't synced recently — always check for empty responses and display 'No recent data' rather than showing stale cached values.
- Monitor API quota usage through the Garmin Developer Portal — the Health API has request limits per day that vary by partner approval level.
- Test thoroughly in Garmin's sandbox environment before requesting production access — the sandbox provides mock data for all data types and allows you to verify your integration without real user data.

## Use cases

### Build a corporate wellness program dashboard

Create a Retool dashboard showing aggregated fitness metrics for employees enrolled in a corporate wellness program. Display step count trends, average sleep duration, active minutes, and stress scores — all anonymized and aggregated to protect individual privacy while giving wellness coordinators the program-level insights they need.

Prompt example:

```
Build a Retool wellness dashboard showing weekly aggregated Garmin metrics for enrolled users. Show average daily steps, average sleep duration, average active minutes, and heart rate range as stat components. Include a line chart of step count trend over 30 days. Add a Table of daily summaries per user (with user ID, not name) for detailed analysis.
```

### Build an activity analysis tool for coaches

Create a Retool panel for sports coaches to view athlete training data from Garmin devices. Display recent activities with distance, duration, pace, heart rate zones, and training load. Coaches can identify athletes who are overtraining or underrecovering and adjust training plans accordingly.

Prompt example:

```
Build a Retool coach dashboard showing Garmin activity data for a selected athlete. Show recent activities in a Table with type, date, distance, duration, average heart rate, and calories. Add a chart showing training load over the last 4 weeks. Include sleep score and recovery data from the previous night.
```

### Build a personal health tracking panel

For developers approved for the Garmin Health API, build a personal Retool dashboard combining multiple Garmin data streams: daily step counts, sleep stages, heart rate variability, body battery, and stress scores. This creates a comprehensive health dashboard that goes beyond what Garmin Connect's native mobile app shows.

Prompt example:

```
Build a personal Retool health dashboard showing my Garmin daily summaries for the last 30 days. Show a line chart of steps per day, a stacked bar chart of sleep stages (light/deep/REM/awake), and a scatter plot of HRV vs sleep quality. Include daily stress scores and body battery end-of-day values.
```

## Troubleshooting

### All Garmin API calls return 401 Unauthorized despite valid credentials

Cause: OAuth 1.0a request signatures are time-sensitive. If the server clock is out of sync by more than a few minutes, Garmin rejects the signature as expired. This is also caused by incorrect signature construction.

Solution: Ensure your signing proxy or signing code uses the current UTC Unix timestamp. Verify the HMAC-SHA1 signature key format: it must be url_encode(consumer_secret) + '&' + url_encode(token_secret). Check the signature base string is correctly formed as METHOD&encoded_url&encoded_params.

### Getting 403 Forbidden with 'insufficient permissions' on wellness endpoints

Cause: Your Garmin Health API partner credentials may not have been approved for all data categories. Garmin grants access to specific data types per application.

Solution: Log into the Garmin Developer Portal and check which wellness data categories your application has been approved for. Contact Garmin's developer support to request access to additional data types. The approval level determines which endpoints return data vs 403.

### API returns empty results for a date range where data exists

Cause: Garmin's API filters by upload time, not activity date. Data uploaded recently might have an activity date from days ago. The uploadStartTimeInSeconds/uploadEndTimeInSeconds parameters filter by when data was synced to Garmin's servers, not when the activity occurred.

Solution: Use a wider date range for the upload time window. If looking for activities from last week, set the upload time window to the last 7-10 days to capture any recently synced historical data. Garmin recommends querying a rolling window (e.g., last 24 hours) on a schedule rather than large one-off date ranges.

### Garmin Health API application was rejected or not approved

Cause: Garmin has specific criteria for API access and rejects applications that don't clearly articulate a health-related use case with appropriate data privacy practices.

Solution: Revise your application with a more specific use case, explicit data retention and deletion policies, and information about your organization's privacy compliance (HIPAA, GDPR). Garmin is more likely to approve healthcare organizations, certified wellness programs, and established fitness platforms than general-purpose tools.

## Frequently asked questions

### Does Retool have a native Garmin Connect connector?

No. Retool connects to Garmin Connect via a REST API Resource using Garmin's Health API. The main prerequisite is being approved as a Garmin Health API partner — without approval, you cannot access Garmin's wellness data endpoints. Once approved and authenticated, all data is available through standard REST API queries in Retool.

### Why does Garmin require a partner program application instead of self-service API access?

Garmin restricts API access because their platform contains sensitive health data. The partner review process ensures that applications accessing user health metrics have appropriate privacy practices, clear consent mechanisms, and legitimate use cases. Consumer fitness data is classified as sensitive under GDPR and similar regulations, and Garmin's gated access model helps manage this compliance responsibility.

### What is OAuth 1.0a and why does Garmin use it instead of OAuth 2.0?

OAuth 1.0a is an older authentication standard that requires cryptographic request signing. Each API call is signed using HMAC-SHA1 with your credentials, making request interception attacks practically impossible even without HTTPS. OAuth 2.0 relies on Bearer tokens which are simpler but depend entirely on HTTPS for security. Garmin uses OAuth 1.0a for the additional security layer it provides for sensitive health data.

### How do I handle Garmin data for multiple users in a corporate wellness program?

Each enrolled user must individually authorize your application through Garmin's OAuth 1.0a flow. After authorization, you store each user's access_token and token_secret in your secure database. When building Retool queries for a specific user, retrieve their tokens from the database and use them to sign API requests. Token management (enrollment, revocation, expiry handling) is the primary technical complexity of multi-user Garmin integrations.

### Can I access Garmin Connect data without the Health API partner program?

There are unofficial libraries (like garth in Python) that access Garmin Connect's internal APIs by mimicking the mobile app's authentication. However, this approach violates Garmin's Terms of Service and is not recommended for production or corporate use. The only compliant method for third-party application access to Garmin data is through the official Health API partner program.

---

Source: https://www.rapidevelopers.com/retool-integrations/garmin-connect
© RapidDev — https://www.rapidevelopers.com/retool-integrations/garmin-connect