If you're building anything that connects health data to AI, your first practical question is which wearable APIs are actually pleasant to integrate against. This piece is from someone who's read all of them.
The criteria that matter:
- Documented and stable. Public docs, predictable shapes, no quiet breaking changes.
- OAuth not weird. Standard authorization code flow with refresh tokens, sane scopes.
- Useful data. Sleep stages, HRV, workouts, daily activity at minimum.
- Webhook support. So you can react to new data without polling.
Here's how the major ones stack up.
1. WHOOP
Developer portal. HRV in ms_rmssd.
WHOOP's API is the cleanest of the big five. OAuth 2.0 flow is standard, scopes are sensible, the data shapes are well-documented, and you get sleep, recovery, strain, workouts, and HRV in a consistent JSON schema. Webhooks notify you when new data lands.
The downside: subscription-only ($239/year), so anyone you're integrating for has to be a paying WHOOP user. The data depth is excellent if they are.
2. Polar
AccessLink API. HRV in ms_rmssd.
Polar's AccessLink is older and less polished than WHOOP's developer portal, but the underlying API is solid. Sleep stages, training sessions, daily activity, Nightly Recharge, Cardio Load, SleepWise data; depending on the model, you get a lot. Vantage V3 and Pacer Pro expose the full set; entry trackers expose less.
Webhook support is real but the documentation is lean. OAuth is standard.
3. Oura
Cloud API. HRV in ms_rmssd.
Oura's API is well-documented and the v2 endpoints are stable. You get sleep, readiness, activity, heart rate, HRV, and workouts. OAuth is standard.
The catch is the subscription tier. The hardware is $349, but the API returns data only for users with an Oura membership ($69.99/year). Without it, Gen3 and later rings return no data through the API.
4. Withings
Developer API. HRV in ms_rmssd.
Withings' API covers a wider range than the others because their hardware does too: scales, sleep mats, blood pressure cuffs, watches. The developer experience is competent, OAuth standard, data shapes consistent.
The minor friction is that Withings auth flows have historically had region-specific quirks (EU vs US OAuth domains). Worth testing in production once before launching anywhere.
5. Suunto
Developer portal. HRV in ms_rmssd.
Suunto's API is multisport-focused: workouts, training metrics, occasional sleep. Less depth than the top four for general health, but if you're building something endurance-specific it's the right fit. OAuth standard, docs reasonable.
Honorable mentions
- Hevy (https://api.hevyapp.com/docs): not a wearable but a strength-training app with a public API. Useful if you're building anything that integrates lifts.
- Intervals.icu (https://intervals.icu/api/v1/docs): aggregator that pulls from Garmin, Strava, etc. Useful if you want endurance analysis as a single feed.
- Dexcom (https://developer.dexcom.com/): CGM, not a wearable in the traditional sense, but their API is the standard for glucose data.
- Apple HealthKit: not a web API, iOS-only. If you're building inside an iOS app it's the right path. If you're building a web service, you can't use it directly.
What about MCP-shaped APIs?
If you're specifically building for AI agents, the MCP-shaped path is to put a server in front of these APIs and expose a single uniform tool surface. That's what Freddy does. It reads from Polar, Oura, WHOOP, Withings, Suunto, Hevy, Intervals.icu, and Dexcom and exposes them to any MCP client. Saves you from writing six OAuth flows yourself.
If you'd rather build the integration yourself, all of the APIs above are fine starting points. WHOOP and Oura are the easiest to get running.
APIs evolve; check the linked developer portals before committing implementation work.