You're building a product that uses wearable health data. The first device integration feels manageable — read the docs, call the endpoints, store the data. This page is about everything that comes after.

The Build-It-Yourself Iceberg

Each device you add multiplies the complexity, and the real cost is in the long tail of edge cases.

Device Integration

What you'd build What that actually means
OAuth flows per provider Each device maker has its own OAuth implementation, token refresh logic, and error semantics. Garmin uses OAuth 1.0a. Fitbit uses OAuth 2 with PKCE. Apple Health has no OAuth — it's on-device only.
On-device SDKs Apple Health (HealthKit) and Health Connect require native iOS/Android code. You need background sync, permission management, and graceful handling of OS-level restrictions.
Webhook receivers Most cloud-connected devices push data via webhooks. Each provider has different payload formats, retry behavior, and signature verification schemes.
Ongoing maintenance Device APIs change without warning. Garmin has deprecated endpoints mid-year. Fitbit moved scopes between API versions. Apple adds new HealthKit types every iOS release.

Data Normalization

Raw wearable data is inconsistent across every dimension:

  • Units — Garmin reports distance in meters. Fitbit uses miles or kilometers depending on user locale settings. Apple Health uses meters but with different type identifiers. Oura reports body temperature as a deviation from baseline rather than an absolute value.
  • Timezones — Some devices report in UTC, others in the user's local time, others in the device's last-known timezone. Sleep sessions that cross midnight are especially tricky.
  • Granularity — Heart rate might arrive as 1-second samples during workouts (Apple Watch), 15-second intervals (Garmin), or daily resting averages without intraday access (Fitbit).
  • Naming — "Active calories" vs "calories burned" vs "energy expenditure" vs "total calories" — every provider uses different terminology for overlapping concepts.
  • Deduplication — A user with an Apple Watch and an iPhone will report steps from both devices. A user who wears a Garmin and an Oura Ring will have overlapping heart rate data.

Building a normalization layer that handles all of this correctly — across every device, every data type, and every edge case — is a significant engineering investment.

Health Scores

Raw data alone doesn't tell users much. Turning "resting heart rate was 58 bpm, HRV was 42ms, you slept 6.5 hours with 1.2 hours of deep sleep" into "your recovery is 64/100 — moderate, take it easy today" requires:

  • Personal baselines — a resting heart rate of 58 bpm is excellent for one person and elevated for another. Absolute values are meaningless without individual context built over weeks of data.
  • Cross-device calibration — a Garmin's HRV algorithm produces different values than an Apple Watch for the same person at the same time. Scores must account for device-specific signal characteristics.
  • Temporal modeling — sleep quality affects next-day recovery, which affects strain capacity, which feeds back into stress. These aren't independent metrics — they're a system with time-lagged dependencies.
  • Sparse data resilience — what happens when a user has 2 days of data? When they forget their watch for a day? When they switch from Garmin to Oura mid-week? Scores need to degrade gracefully, not break.

Build vs. Buy

Factor Build it yourself Use Sonar
Time to first integration 2-4 weeks per device Hours
Ongoing maintenance Dedicated engineer(s) Zero — Sonar handles API changes
Device coverage Limited by team bandwidth 60+ devices, growing
Health scores Months of R&D Out of the box
Mobile SDKs Build and maintain per platform Drop-in packages
Data quality Your normalization pipeline Battle-tested across millions of data points

Ready to Try It?

The Quickstart gets you from zero to querying health scores in minutes — no device required. Sonar's sandbox comes pre-loaded with realistic wearable data so you can explore the API immediately.