How to Integrate Retool with Garmin Connect

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.

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.

1// OAuth 1.0a Authorization header format (for reference)
2// The header value looks like:
3// OAuth realm="",
4//   oauth_consumer_key="your_consumer_key",
5//   oauth_nonce="random_string",
6//   oauth_signature="base64_hmac_sha1_signature",
7//   oauth_signature_method="HMAC-SHA1",
8//   oauth_timestamp="unix_timestamp",
9//   oauth_token="user_access_token",
10//   oauth_version="1.0"
11
12// The signature base string is:
13// HTTP_METHOD&url_encoded(base_url)&url_encoded(sorted_params_string)
14// Signed with HMAC-SHA1 key: url_encode(consumer_secret)&url_encode(token_secret)

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}.

1// Garmin Health API endpoint overview:
2// Base URL: https://healthapi.garmin.com/wellness-api/rest
3//
4// Key endpoints:
5// GET /dailies - Daily activity summaries
6// GET /activities - Detailed activity data
7// GET /sleeps - Sleep tracking data  
8// GET /body-composition - Weight, BMI data
9// GET /stress - Stress level data
10// GET /heart-rate-variability - HRV summaries
11// GET /respiration - Breathing rate data
12// GET /user-metrics - User fitness metrics
13//
14// All endpoints accept uploadStartTimeInSeconds and uploadEndTimeInSeconds
15// as Unix epoch timestamps for date range filtering

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.

1// Transformer for Garmin daily summaries
2const dailies = data.dailies || [];
3return dailies.map(day => ({
4  date: day.calendarDate,
5  steps: day.steps || 0,
6  distance_km: day.distanceInMeters ? (day.distanceInMeters / 1000).toFixed(2) : '0',
7  active_minutes: day.activeTimeInSeconds ? Math.round(day.activeTimeInSeconds / 60) : 0,
8  floors: day.floorsClimbed || 0,
9  calories: day.activeKilocalories || 0,
10  avg_heart_rate: day.averageHeartRateInBeatsPerMinute || 0,
11  max_heart_rate: day.maxHeartRateInBeatsPerMinute || 0,
12  body_battery_low: day.minBodyBattery || null,
13  body_battery_high: day.maxBodyBattery || null,
14  stress_avg: day.averageStressLevel || null
15}));

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.

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

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.

1-- SQL query to fetch user's Garmin tokens
2-- Use this in a Retool database Resource query
3SELECT 
4  u.id,
5  u.display_name,
6  u.department,
7  gt.garmin_access_token,
8  gt.garmin_token_secret,
9  gt.enrolled_at
10FROM users u
11JOIN users_garmin_tokens gt ON u.id = gt.user_id
12WHERE u.id = {{ select_user.value }}
13  AND gt.revoked_at IS NULL
14LIMIT 1;