Wearable API Integration Engineering

There are two broad access models. Cloud APIs, offered by vendors such as Fitbit, Garmin, Oura, Withings and Polar, let your server retrieve data after a user authorizes your application. On-device platforms, Apple HealthKit and Google Health Connect, store data on the phone and have no vendor cloud endpoint, so your own mobile app must read the data and send it to your backend.

Many products need both. A patient on iPhone with an Apple Watch is reachable only through HealthKit, while a Garmin user can be reached through the Garmin Health API without your app. We design the backend so both paths feed the same ingestion pipeline and canonical model.

Several vendors gate API access. Garmin's Health API requires an approved business developer application. Fitbit's Web API is OAuth 2.0 based, and intraday time series for server applications require a request to Fitbit with a description of your use. Samsung's health SDKs may require partner approval for some data. Google Play requires a health permissions declaration for apps reading Health Connect data.

These steps often take longer than the engineering. We help you prepare applications with accurate descriptions of your use case, data handling and privacy practices, and we sequence build work so a pending approval does not leave the team idle. We do not hold official partnerships with these vendors; access is granted to your organization under each vendor's terms.

Each connected user carries an access token, a refresh token and a set of granted scopes. Tokens expire, refresh tokens can be rotated or invalidated, and users can revoke access from the vendor's app at any time. A production integration needs to handle every one of these states without manual intervention.

Most wearable APIs offer webhooks or subscriptions that notify you when a user's data changes. The notification usually says what changed, not the data itself, so your system queues a fetch. We build these handlers to verify signatures where vendors provide them, respond quickly, and process asynchronously so a burst of notifications does not cause timeouts.

Many vendors enforce per-user rate limits, and some also enforce application-wide limits. Backfilling months of history for a new cohort can hit those limits fast. We schedule fetches with per-user budgets, back off on rate-limit responses, and prioritize recent data so clinicians see today's readings before historical backfill completes.

Wearable data is also revised after the fact: a watch syncs late, sleep is re-scored, or a user edits an entry. The sync logic treats records as upserts keyed on vendor identifiers and time ranges, so late corrections replace earlier values instead of duplicating them.

Vendors model the same concept differently. Heart rate may arrive as one-second samples, one-minute averages or daily resting values. Sleep may be staged intervals or a summary score. We map every source to a canonical model with UCUM units, explicit timezone offsets, device and app provenance, and the original payload retained for audit.

That model is what your product, analytics and clinical systems consume. When data needs to go to an EHR, the same model maps to FHIR Observations with LOINC codes. See FHIR wearable integration for how that mapping is handled.

Vendor APIs change, endpoints are deprecated (Google Fit is the clearest recent example), and outages happen. We build monitoring around sync lag, error rates per vendor, token failure rates and webhook delivery so problems are visible before users report missing data.

Handover includes runbooks for common failure modes, dashboards for sync health and documentation of each vendor integration's assumptions, so your engineering team can operate and extend the system.