Garmin Health API: at a glance
Summary based on publicly available vendor documentation. Vendor terms, endpoints and limits change; we verify them against current documentation at the start of every project.
- Integration methods
- Garmin Health API and Activity API via the Garmin Connect Developer Program
- OAuth-based user consent linking Garmin Connect accounts
- Push delivery or ping/pull notification to your HTTPS endpoints
- Backfill requests for historical data within program limits
- Health SDK (Standard or Companion) for direct BLE device data, separately licensed
- Data types
- Daily summaries and 15-minute epoch summaries
- Heart rate and user metrics
- Sleep summaries
- Stress and Body Battery
- HRV status
- Pulse ox and respiration
- Activities and activity details
- Authorization requirements
- Organization approval to join the developer program
- User consent through Garmin's OAuth flow
- Users can disconnect your application from Garmin Connect
- Per-user permission settings for which data is shared
- Developer approval & agreements
- Application to the Garmin Connect Developer Program and approval by Garmin
- Acceptance of Garmin program terms; commercial terms may apply
- Separate license agreement for the Health SDK
- Program details verified against current Garmin documentation at project start
- API limitations
- Not available for individual or hobby use
- Data arrives as summaries after the device syncs with Garmin Connect
- Backfill of historical data is limited in range
- Available metrics vary by device model and firmware
- Endpoints must be available and respond reliably to deliveries
- Healthcare use cases
- Clinical research and decentralized trials
- Remote patient monitoring
- Sleep and stress programs
- Cardiac rehabilitation and activity tracking
- Corporate wellness programs
Developer Program Access
Garmin's Health API is not an open API. Organizations apply to the Garmin Connect Developer Program, describe their use case, and receive access if approved. The program is aimed at businesses, healthcare organizations and research institutions; it is not intended for personal projects.
Approval timelines and terms are set by Garmin, and commercial terms may apply depending on the use case. We help you prepare a clear description of the data you need and how it will be used, but approval remains Garmin's decision and is planned as a project dependency.
Integration Architecture: Push and Ping/Pull
After a user links their Garmin Connect account through OAuth, Garmin sends data to endpoints you register. In push mode, the summary data is delivered directly in the request. In ping/pull mode, Garmin sends a notification and your server calls back to retrieve the data within the allowed window.
Both modes require endpoints that are reliably available, respond quickly and process deliveries idempotently. We build receivers that acknowledge fast, queue work for asynchronous processing and record raw payloads for reprocessing.
- HTTPS receivers for each summary type
- Fast acknowledgement with queued processing
- Deduplication by user, summary type and time window
- Backfill jobs that respect program limits
Data Types
The Health API delivers daily summaries, 15-minute epoch summaries, sleep, stress, Body Battery, HRV status, pulse ox, respiration, heart rate and user metrics. The Activity API provides recorded activities and their details. Exact fields depend on the device model and firmware, so we define the data contract against the devices your program supports.
For programs that need raw or near-real-time device data in a mobile app, the Health SDK connects to supported Garmin devices over Bluetooth. It is licensed separately and is a different integration path from the cloud API; see our Bluetooth device integration work for that style of build.
Limitations to Plan For
Data reaches Garmin only after the device syncs, usually through the Garmin Connect app, so delivery timing depends on user behaviour. Historical backfill is limited in range, which matters for studies that want baseline data from before enrolment.
Summaries are calculated by Garmin's algorithms, which can change with firmware updates. For research and clinical use we record device model and firmware where available so analysts can account for changes. Consent and access logs support HIPAA-aligned operations.
Sync-dependent timing
Deliveries follow device syncs, not measurement time.
Limited backfill
Historical data requests are capped in range.
Device variation
Available metrics differ across models and firmware versions.
Healthcare Use Cases
Garmin integrations support clinical research and decentralized trials, remote patient monitoring, sleep and stress programs, cardiac rehabilitation and wellness programs, particularly where participants already own Garmin devices or long battery life is useful.
Garmin's wellness metrics are not a substitute for clinical-grade measurement unless validated for the intended use. We help teams decide which metrics support trend monitoring and which findings need clinical confirmation, and we can route data to clinical systems through FHIR-based integration.
Frequently asked questions
Can anyone access the Garmin Health API?
No. Access is through the Garmin Connect Developer Program for approved business developers. Organizations apply, and Garmin decides whether to grant access.
What is the difference between push and ping/pull?
In push mode Garmin delivers data directly to your endpoint. In ping/pull mode Garmin sends a notification and your server retrieves the data. Both require reliable endpoints.
Can we get historical data when a user enrols?
Backfill is available within limits set by Garmin. Programs that need longer baselines should confirm current limits during planning.
What is the Garmin Health SDK?
A mobile SDK for connecting directly to supported Garmin devices over Bluetooth. It is a separate integration path and requires its own license agreement.
Is Garmin data suitable for clinical decisions?
Garmin metrics are consumer wellness data. They should not replace clinical-grade measurement unless validated for the specific use, and clinical workflows should reflect that.