Garmin Connect API: Developer Guide for Activities and Health Metrics
Key Takeaways
- The Garmin Health API uses push-based data delivery: Garmin sends data to your registered callback URLs when a user syncs their device, not when you request it
- Authentication uses OAuth 1.0a with signed requests, which requires a library rather than manual implementation
- Available data includes 100+ activity types, GPS, heart rate, HRV, sleep, Body Battery, stress, VO2 max, respiration and body composition
- Full server-side access requires applying to Garmin's Health API partner program
- Open Wearables handles OAuth 1.0a signing, push notification registration and callback processing across all Garmin data types
Introduction
Garmin occupies a specific position in the wearable market. Their devices are trusted by endurance athletes, military users, outdoor adventurers and sports scientists who prioritize battery life, GPS accuracy and sensor depth over sleek consumer aesthetics. The Garmin API reflects this heritage: it covers over 100 sport types with detailed per-activity data including running dynamics, cycling power metrics, swim stroke analysis and altitude tracking.
For developers building serious fitness or performance applications, Garmin data is uniquely rich. But the API is also one of the more technically demanding integrations in the wearable space. It uses OAuth 1.0a rather than the OAuth 2.0 that most modern APIs have standardized on. Data delivery is push-based, meaning Garmin sends data to your server rather than waiting for you to request it. And full access requires a partnership application rather than a self-serve developer account.
This guide covers what the Garmin API provides, how its push architecture works, what authentication requires in practice, and how to handle the operational complexity of a production Garmin integration.
What Garmin Exposes
Garmin's data coverage is broader than any other wearable API in terms of sport types and activity metrics. Over 100 sport types are supported with type-specific data. Running activities include not just time, distance and heart rate but also running dynamics: cadence, stride length, ground contact time, vertical oscillation, vertical ratio and ground contact time balance. These are signals that most wearable APIs do not expose at all. Cyclists get power (watts, normalized power, intensity factor, training stress score), cadence and FTP-based training load. Swimmers get stroke type, SWOLF score, strokes per length and pool length.
For health and recovery monitoring, Garmin provides: Body Battery (a proprietary 0-100 energy indicator that accounts for HRV, stress and sleep), daily stress score, resting heart rate, nightly HRV, sleep staging and score, respiration rate, SpO2, and VO2 Max estimated from running and cycling activities. Body composition is available for users with compatible Garmin scales (Garmin Index) including weight, BMI, body fat percentage, muscle mass, bone mass and body water.
Daily summaries aggregate step count, floors climbed, active calories, BMR calories, intensity minutes and stress levels throughout the day.
Push-Based Delivery
The fundamental architectural difference between Garmin and most other wearable APIs is that Garmin delivers data to you rather than waiting for you to fetch it. This is not a webhook notification that triggers a subsequent API call. Garmin pushes the full data payload directly to your registered callback URL when a user syncs their device.
You register separate callback URLs for each data type you want to receive: activities, daily summaries, epochs (activity-level data by minute), sleep, body composition, stress, user metrics (VO2 Max estimates), pulse oximetry, respiration and HRV. Each has its own endpoint. When a Garmin device syncs, Garmin's backend processes the data and POSTs it to the appropriate URLs for all users who have authorized your application.
The practical implications of this architecture are significant. Your callback endpoints must be publicly reachable with valid HTTPS certificates at all times. If your endpoint is down when Garmin attempts delivery, Garmin will retry, but there is no guarantee of delivery. You must design for idempotent processing because Garmin may send the same data multiple times. And you must respond to each incoming request with HTTP 200 within a few seconds, which means your handler needs to queue the actual processing asynchronously rather than doing it inline.
Authentication: OAuth 1.0a
Garmin uses OAuth 1.0a for authentication. This is not a typo or an oversight: Garmin's Health API predates the widespread adoption of OAuth 2.0 and has not been migrated. OAuth 1.0a requires signed requests using HMAC-SHA1, which is significantly more complex to implement correctly than OAuth 2.0's Bearer token model.
In practice, this means using a library. For Python, requests-oauthlib handles the signing correctly. For Node.js, oauth-1.0a is reliable. Do not attempt to implement the signing algorithm manually unless you have deep experience with OAuth 1.0a: subtle mistakes in parameter encoding, timestamp handling or nonce generation produce invalid signatures that are difficult to debug.
The OAuth 1.0a flow produces an access token and an access token secret (not just a token). Both are required for every signed request. Store both securely per user. Unlike OAuth 2.0 access tokens, Garmin's OAuth 1.0a tokens do not expire on a fixed schedule, which removes the token refresh complexity present in providers like Strava or Whoop. However, users can revoke access through their Garmin Connect account settings, and your code needs to handle the resulting 401 responses gracefully.
Access Requirements
Garmin's Health API is not available as a self-serve developer credential. Full server-side access to user health data through the push notification system requires applying to Garmin's Health API partner program. The application asks about your use case, your company, your data handling practices and your integration plans.
Garmin offers different access tiers. Consumer-facing applications can apply through one channel. Research and clinical applications have a separate pathway. The approval process typically takes days to weeks depending on the completeness of your application and Garmin's current review queue.
For prototyping and development purposes, Garmin provides a health API sandbox that allows testing without full partner approval. The sandbox generates synthetic data that mirrors the structure of real device data, which lets you build and validate your push handler logic before real user data arrives.
Body Battery
Body Battery is Garmin's proprietary energy level indicator, scored from 0 to 100. It combines HRV analysis, stress detection and sleep quality into a running estimate of the user's available energy reserve. Body Battery depletes during the day as activity and stress accumulate, and recharges during sleep.
Body Battery is available in daily summaries, including the peak value for the day and the low value. It is one of Garmin's most user-loved features and a differentiator compared to most competitors. If your app targets Garmin users, surfacing Body Battery prominently is worth doing.
Open Wearables and Garmin
Open Wearables handles Garmin's OAuth 1.0a authentication, push notification endpoint registration, callback processing and data normalization. Instead of building and maintaining signed OAuth request infrastructure and individual callback handlers for every Garmin data type, you configure your Open Wearables instance with Garmin credentials and receive normalized activity and health data through a simple query API.
The platform abstracts Garmin's push model behind a consistent interface. You query Open Wearables for a user's activity data the same way you query for Strava or Polar data, regardless of the underlying delivery mechanism each provider uses.
FAQ
Why does Garmin use OAuth 1.0a instead of OAuth 2.0?
Garmin's Health API was built before OAuth 2.0 became the standard and has not been migrated. This is a known friction point for developers, and it is the most common complaint about the Garmin integration experience. Use a library to handle the signing.
Do I need a physical Garmin device to develop against the API?
For testing with the push sandbox, no. The sandbox generates synthetic data that mirrors real device payloads. For testing with real data including all activity types and device-specific metrics, a physical Garmin device is necessary.
How quickly does Garmin push data after a device sync?
Typically within one to five minutes of device sync. Delivery speed depends on Garmin's backend processing load. There is no real-time delivery guarantee.
How do I handle idempotent processing of Garmin push events?
Use Garmin's activity IDs and summary IDs as natural keys in your database with upsert operations. A duplicate delivery of the same activity should update the existing record rather than creating a duplicate. Design your processing to be safe to run multiple times on the same payload.
Does Open Wearables support all Garmin data types?
Open Wearables normalizes the core data types: activities, daily summaries, sleep, HRV and health metrics. Garmin-specific metrics like running dynamics are passed through where available in the activity payload.
Garmin Integration
View the full Garmin integration documentation on Open Wearables.
See Related Articles
Garmin API Push Notifications: How Callback Sync Works
Strava API Developer Guide: Activities, Heart Rate and GPS Data
