Sonar
You've seen Sonar in action — created a user and queried health data in the sandbox. This section covers how the platform works end to end, starting with two foundational concepts and then walking through the data pipeline.
Foundations
User Model
A Sonar user is the container for all device connections and health data belonging to one of your end-users. You create users via the API, link them to your identity system with a reference_id, and everything else — devices, metrics, scores — hangs off that user.
Data Model
Raw wearable data flows through three layers: raw (device-native format), normalized (unified schema, consistent units), and canonical (deduplicated best value across all sources). You always query the canonical layer — Sonar handles everything upstream.
The Pipeline
Device Connectivity
200+ wearable devices across 60+ integrations, connected through two paths. A Mobile SDK reads from on-device health stores (Apple Health, Health Connect). A Cloud API handles OAuth-managed wearables (Garmin, Fitbit, Oura, and more). Once connected, data syncs automatically — including historical backfill.
Data Catalog
Every device speaks a different language. Sonar normalizes all of it into consistent metrics across seven categories — activity, sleep, vitals, body composition, energy, nutrition, and computed scores. One schema, one set of units, regardless of source.
Health Scores
Eight scores (0–100) computed from the raw metrics: Recovery, Strain, Sleep, Stress, Inactive Stress, Sleep Stress, Nutrition, and Energy Reserve. Personal baselines, cross-device calibration, and temporal modeling are handled for you — scores update automatically as new data arrives.
Data Delivery
Two ways to know when data changes — poll an events log or receive webhook push notifications. Both are notifications that tell you what's new; you fetch the actual data through the REST API. Use either or both.