How to integrate wearable data into your app (2026 guide)

Most teams discover the real shape of a wearable integration about three weeks after the first successful API call. The call itself is easy. What follows is a long tail of token refresh, webhook registration, backfill, restated data and vendor schema changes, spread across a dozen providers that each made slightly different decisions about what a “sleep” or a “workout” is. This guide walks through that long tail so you can decide, with your eyes open, whether to build the plumbing yourself or buy it, and how to structure the work either way.

It is written for engineers. There are no benchmark numbers or vendor rankings here, only the mechanics that will determine whether your integration is still healthy a year after launch.

Build vs buy: an honest framework

The build-versus-buy decision is usually made on the wrong number. Teams estimate the cost of reaching the first API response, which is small, and then discover that the cost lives elsewhere. Per provider, the recurring work looks like this:

• OAuth refresh and revocation. Tokens expire, users revoke access from the vendor app, and providers rotate refresh tokens on use. Every one of these has to be handled without the user noticing.
• Webhook registration and re-registration. Some providers register subscriptions per user, some per app, some expire them. A subscription that quietly lapses looks exactly like a user who stopped wearing the device.
• Backfill on first connect. A new user expects to see history immediately. Pulling it under a rate limit without starving live traffic is its own scheduler.
• Revisions. Providers restate sleep, HRV and recovery figures after later syncs. If your pipeline treats every payload as new, you get duplicates; if it ignores repeats, you keep stale data.
• Deduplication across sources. One user, one run, two copies: one from Strava, one from Health Connect. Somebody has to decide which wins.
• Vendor schema changes. Fields get renamed, units change, v1 endpoints are retired. Each change is small; the sum is a permanent maintenance rota.

Building in-house is the right call when you need one or two providers and no more, when you already have an iOS or Android team (which you need anyway for the on-device stores), or when your data-flow constraints rule out a third party touching the data at all. In those cases the maintenance rota is bounded and you keep full control.

An aggregator is the right call when the provider list is long or growing, when you want the on-device and cloud sources to arrive in the same shape, or when the engineering time is better spent on the product that sits on top of the data. The trade is a per-user or per-tier fee and a dependency on someone else’s uptime, so evaluate the vendor’s hosting and data-handling terms as carefully as its endpoint list.

The provider landscape in three groups

“Wearable API” covers three quite different access models, and the difference decides what kind of team you need.

The second row matters more than it looks. Apple Health is where most iPhone users’ Apple Watch data lives, and it never leaves the phone unless an app on that phone moves it. If your product is web-only, you cannot reach it, regardless of which aggregator you pick. Plan for a mobile SDK or a companion app from day one if those users matter to you.

The third row is about time, not code. The Garmin adapter can be written in a week; the agreement that turns it on is a business process on Garmin’s timetable. Fitbit intraday and Dexcom production follow similar patterns. Sequence your roadmap around the approvals, not the engineering.

The plumbing, provider by provider

Every cloud provider needs the same five pieces. The details differ; the shape does not.

OAuth and token refresh

All the cloud providers use OAuth 2.0 authorisation-code flow, but they disagree on the details that hurt: whether the refresh token rotates on every use, how long an access token lives, whether scopes can be added later without a fresh consent screen, and how revocation is signalled. Store refresh tokens encrypted at rest, refresh ahead of expiry rather than on failure, and treat a refresh rejection as a state change on the connection that the user needs to see. A connection that has been dead for a month and still shows as “connected” is the most common support ticket in this category.

Webhooks vs polling

Where a provider offers webhooks, use them, because polling under a rate limit does not scale past a few thousand users. But webhooks are a notification, not the data: most providers send an event that says “something changed for this user” and expect you to fetch the record. Verify signatures, respond quickly, fetch asynchronously, and keep a scheduled reconciliation pass so a dropped notification cannot become a permanent hole. We go into the trade-offs in detail in webhooks vs polling for wearable data.

Backfill on first connect

Decide up front how much history you pull. Thirty to ninety days is a common window; more than that competes with live traffic for the same rate limit. Run the backfill as a resumable job keyed by user and date range, record progress, and expose a “history loading” state to the product so it does not draw a chart with a cliff in it. If a provider offers bulk endpoints, use them; if it only offers per-day endpoints, the scheduler needs a per-provider concurrency cap.

Revisions

Wearable data is not append-only. A sleep record for last night can change at 07:00 when the ring syncs, again at 09:00 when the phone uploads a fuller dataset, and again when the vendor’s own processing revises the staging. HRV and readiness values move with it. Your storage needs a stable identity for each record (provider, user, the provider’s id or a deterministic hash of type and start time) and an upsert path that replaces the previous version. Keep a revision counter so downstream consumers can tell a restatement from a new record and re-run anything they derived from it.

Deduplication across overlapping sources

A user with a Garmin watch, the Strava app and an Android phone can deliver the same 10 km run through three routes: Garmin’s cloud, Strava’s cloud, and Health Connect on the phone. The timestamps will differ by a few seconds, the distances by a few metres. You need a matching rule (same type, overlapping interval above a threshold) and a source-priority rule per data type, and both have to be applied before anything is shown to the user. Whichever rule you pick, keep the losing copies rather than discarding them; the priority order will change and you will want to replay it.

Normalisation: what is honest and what is not

Normalisation is where aggregator marketing gets loose, so it is worth being precise about which fields can genuinely be made comparable.

Can be normalised: units (metres, seconds, beats per minute, kilograms), timestamps and time zones (store the offset the device reported, not just UTC, because “last night” is a local concept), session boundaries (one sleep session, one workout, with a start and an end), and field names. This is mechanical work and it removes most of the per-provider branching from your application code.

Cannot be normalised: proprietary scores. Oura’s readiness, WHOOP’s recovery and strain, and the equivalents from other vendors are each computed from different inputs with unpublished weightings. They are not the same quantity on different scales; they are different quantities. Sleep stage taxonomies also differ: some providers report light, deep and REM, others collapse or split those differently, and the staging algorithms are not interchangeable. HRV is the sharpest example: one provider reports rMSSD, another SDNN, and the two are not convertible. Pass these through with the provider label attached and let the product decide how to present them. See the HRV data page for how WearLink labels the statistic rather than hiding it.

Here is the kind of object a normalisation layer should produce for a sleep summary. The values are illustrative, not a real user’s data, and the field names are generic rather than any vendor’s schema.

{
  "provider": "oura",
  "user_id": "usr_8f2c1a",
  "type": "sleep",
  "start": "2026-08-30T22:41:00+01:00",
  "end": "2026-08-31T06:52:00+01:00",
  "total_seconds": 27540,
  "stages": {
    "awake_seconds": 1860,
    "light_seconds": 13920,
    "deep_seconds": 5460,
    "rem_seconds": 6300,
    "taxonomy": "provider"
  },
  "efficiency_pct": 92.9,
  "source_revision": 2,
  "provider_record_id": "sleep_01j6…"
}

Two details in that example carry weight. stages.taxonomy is explicit about whose staging this is, so a consumer cannot accidentally compare it with another provider’s. source_revision is the counter that lets an event such as sleep.created be re-delivered for the same record without the consumer treating it as a second night.

Launch checklist

The steps below are the order we would run them in for a new provider. Items six to eight are the ones most often skipped, and the ones that cost most to retrofit.

1. Decide which stores you actually need. Separate cloud OAuth providers (readable server-side) from on-device stores (Apple Health, Health Connect, Samsung Health), which require your own mobile app. This decision sets your team shape.
2. Register developer apps and read the access terms. Create the developer app with each provider, note redirect URI rules, rate limits and any approval gate such as Garmin’s commercial agreement, Fitbit intraday approval or Dexcom sandbox versus production.
3. Implement OAuth with refresh and revocation handling. Store refresh tokens encrypted, refresh ahead of expiry, detect revocation and surface a reconnect prompt to the user instead of silently going stale.
4. Choose webhooks, polling or both per provider. Use webhooks where the provider offers them, poll where it does not, and keep a scheduled reconciliation pass regardless so a missed notification cannot become a permanent gap.
5. Backfill on first connect. Pull a bounded window of history when a user connects, respect the provider rate limit, and mark the backfill as complete so the product knows when the data is trustworthy.
6. Give every record a stable identity and revision. Key records by provider, user and the provider’s own id (or a deterministic hash of start time and type). Upsert on that key so restated data updates rather than duplicates.
7. Deduplicate across overlapping sources. The same run can arrive from Strava and from Health Connect. Decide a source-priority rule per data type and apply it consistently before anything reaches the user.
8. Normalise what is comparable, label what is not. Convert units, time zones and session boundaries. Pass proprietary scores through with their provider label. Do not present a readiness score and a recovery score as the same number.
9. Handle consent, deletion and disconnect. Wire up the provider disconnect flow, honour user deletion requests end to end, and log which data was pulled under which consent so you can answer a subject access request.
10. Monitor the integration after launch. Alert on token refresh failures, webhook delivery failures, backfill stalls and schema drift in provider payloads. Silent failures are the most common way a wearable integration degrades.

How WearLink fits

WearLink is one integration for the cloud OAuth providers plus Swift and Kotlin SDKs for the on-device stores. The providers you can connect today via cloud OAuth are Oura, WHOOP, Fitbit, Strava, Withings. Apple Health, Google Health Connect and Samsung Health are read through the mobile SDKs inside your own app. Garmin, Polar, Suunto, Ultrahuman, Dexcom and Eight Sleep have adapters built but production OAuth is not yet approved, so they are listed as in onboarding on the providers page rather than as connectable.

Data arrives as normalised objects of the kind shown above, with units, timestamps and session boundaries handled and proprietary scores passed through with their provider label. Webhooks are signed and delivered via Svix, and a record that a provider restates is re-delivered with an incremented revision rather than dropped or duplicated. The event catalogue and payload shapes are in the docs.

The free tier covers up to 3 connected users, which is enough to build and test against real accounts. Above that the tiers are flat: $99 per month for Developer and $399 per month for Scale. Details are on the pricing page. If you are deciding whether to build the plumbing yourself, the checklist above is the same one we use, and it is a fair way to estimate what you would be taking on.