Cloud OAuth
Garmin API integration
Provider onboardingThe adapter is implemented; the production OAuth application is awaiting provider approval.OAuth application pending
Garmin has the broadest data surface of any provider in the catalogue — if a metric exists in consumer wearables, a Garmin device probably measures it. For endurance, military, occupational-health and research use cases it is frequently non-negotiable.
It is also the hardest integration. Garmin's Health API still uses OAuth 1.0a, which means request signing rather than bearer tokens, and almost no modern HTTP client does it for you. The API is push-only for new data: Garmin posts to your registered callback and there is no polling endpoint to fall back on if you miss a delivery.
Historical data comes through an entirely separate mechanism — an asynchronous backfill request, capped per call, that delivers into the same callback later. Teams building a "connect and see your last six months" onboarding flow routinely discover this after the flow is designed.
Connect a Garmin user
Two calls. The first mints a hosted connect URL for your end-user; the second reads the normalised summaries once they have authorised with Garmin. Subscribe a webhook to receive the same objects as they land.
# 1. Create a connect session for your end-user
# The API key goes in X-WearLink-API-Key, not in Authorization.
curl -X POST https://wearlink.io/api/v1/connections/session \
-H "X-WearLink-API-Key: $WEARLINK_API_KEY" \
-H "Content-Type: application/json" \
-d '{"user_id": "'"$USER_ID"'", "provider": "garmin", "redirect_uri": "https://yourapp.com/connected"}'
# → { "connect_url": "https://wearlink.io/widget/connect?token=...", "expires_in": 3600 }
# Redirect the user there; they authorise garmin and land back on your redirect_uri.
# The token is scoped to that one user — it is safe to put in a browser URL.
# 2. Pull normalised data whenever you want
curl -H "X-WearLink-API-Key: $WEARLINK_API_KEY" \
"https://wearlink.io/api/v1/users/$USER_ID/summaries?provider=garmin&days=7"Garmin data available through WearLink
- Steps & daily activity
- Sleep stages
- HRV
- Stress & body battery
- SpO2
- Respiration
- VO2 max
- Body composition
- Workouts with full metric streams
Webhook events you can subscribe to
steps.createdsleep.createdstress.createdworkout.createdseries.heart_rate_variability.created
Normalised families this provider feeds: Sleep, Heart Rate Variability, Heart Rate, Workouts, Steps & Daily Activity, Calories & Energy, Recovery & Readiness, Body Composition, Respiratory Rate & SpO2, Stress, VO2 Max & Fitness Metrics.
What makes the Garmin API hard to integrate directly
These are the things that turn an estimated one-week integration into a one-month one.
OAuth 1.0a request signing
Bearer tokens do not apply. Every request needs an HMAC signature over a canonicalised parameter string. This is the single most common reason Garmin integrations take weeks instead of days.
Push-only means missed deliveries are gone
There is no "give me everything since timestamp X" endpoint for regular data. If your callback is down, you need a backfill request to recover — and backfill is rate-limited and windowed.
Backfill is async and capped
The strategy caps historical requests at 30 days per call. Pulling a year means chunked, paced requests whose results arrive over time, not a synchronous response.
Approval is a real gate
Garmin reviews applications for the Health API and does not approve everything. Budget calendar time for it.
FAQ
Garmin API — frequently asked questions
Why is the Garmin API harder than Fitbit or Oura?
Is Garmin live on WearLink today?
Can I get Garmin body battery and stress?
Related
Other cloud integrations
Oura Ring API
Connectable nowThe Oura Ring API (v2) is one of the cleaner wearable APIs to work with — the documentation is accurate and the daily-summary endpoints are stable. The complexity is not in reading it, it is in keeping it read: Oura backfills and revises data after the fact, so a sleep record you fetched this morning can legitimately change by this evening.
WHOOP API
Connectable nowWHOOP's developer API exposes the four objects the product is built around — cycles, recovery, sleep and workouts. The data is high quality and the model is coherent, which makes WHOOP a favourite for recovery and readiness products.
Fitbit API
Connectable nowFitbit has the largest installed base of any dedicated wearable, which makes it the provider most consumer health products need first. It is also the API with the most historical baggage — the surface has accreted since 2011 and it shows in inconsistent date handling and endpoint shapes.
Strava API
Connectable nowStrava is the best-instrumented activity API in the consumer space and the only provider in the WearLink catalogue with a true push model — an activity upload triggers a webhook within seconds, not on a poll cycle. If your product cares about workouts rather than sleep or recovery, Strava is usually the fastest path to a working demo.
Withings API
Connectable nowWithings is the connected-scale and blood-pressure provider, which makes it the one that matters most for clinical-adjacent products — weight management, hypertension programmes, GLP-1 follow-up and remote patient monitoring. Its data is measurement-shaped rather than continuous: discrete readings taken when a user steps on a scale or straps on a cuff.
Polar AccessLink API
Provider onboardingPolar's AccessLink API serves a smaller but committed base — endurance athletes, coaching platforms and sports-science teams. Heart rate quality is the reason people choose it; Polar's chest straps remain a reference standard.
Start with Garmin — free for up to 3 users
No credit card. Your API key is issued at sign-up, and the hosted connect flow works from the first request.