Model wearable observations with provider context
Decide which provider integrations and data types are essential, then distinguish raw provider observations from any product-level interpretation. A single recovery label can hide different algorithms and collection quality across devices.
Normalize time, granularity, and freshness
Store provider, time window, device context, and sync freshness alongside each observation. The interface should name old, missing, or incomparable data and exclude it from current scores according to a visible policy.
Use cross-modality analysis for questions that benefit from it and keep the source visible. A user should be able to see whether a priority came from a recent lab, a wearable trend, a stated goal, or a derived calculation.
The time model is part of the product
Store event time, start and end time, source timezone, ingestion time, and last successful sync. Define how sleep sessions crossing midnight are assigned. Handle daylight-saving changes and user travel explicitly.
A daily value may be reported by the device, calculated by the connector, or aggregated by your platform. Record that origin. Keep raw samples available only when the use case and consent require them.
Connection lifecycle states
Model requested, authorized, active, stale, rate-limited, revoked, and error states. Show the last successful sync and a recovery action. OAuth success does not guarantee usable data if the user has no device history or denied a specific permission.
Use webhooks where providers offer reliable events and scheduled backfills for gaps. Make retries idempotent and record provider cursors so repeated syncs do not duplicate observations.
- Connection status and granted scopes
- Last successful sync
- Provider cursor or watermark
- Backfill window
- User-visible recovery action
Wearable API production gate
- Timezone and day-boundary rules are documented
- Reported and calculated metrics are labelled
- Duplicate syncs do not duplicate data
- Revocation and stale connections update the UI
- Provider outages have retry and status handling
- Cross-modality views keep each source visible
Combine wearable trends with other modalities
WellNizz supports wearable connections and analysis alongside biomarkers, genetics, and health context. Its dashboard contract represents modality coverage and freshness, giving a partial profile a useful state and a clear next connection.
Avoid clinical claims from consumer-device signals
Consumer wearable metrics are wellness observations, not diagnosis or emergency monitoring. Build clear escalation language for concerning symptoms or urgent questions.
Editorial sources
Read the primary guidance
These sources support the technical and health boundaries in this article. Provider prices, availability, and product terms should always be checked at the provider before purchase.
- HealthKitApple Developer Documentation
- Health ConnectAndroid Developers
- OpenAPI Specification 3.1OpenAPI Initiative
Questions, answered
FAQ
What should a wearable data API normalize?
At minimum: provider identity, time window, raw observation, unit where relevant, sync status, and provenance. Derived interpretation should remain distinguishable.
Can wearables and labs be shown together?
Yes, but their collection methods and freshness differ. A good product keeps those differences visible.