Wearable API: Every Wearable, One Integration

How it works

What you build, and what Sahha handles.

Your side is one SDK and a permission prompt. Reading the device, reconciling duplicates across devices, scoring and delivery are all ours.

A

Allow "your app"

Sleep

Heart rate

Workouts

Connect

9:41LIVE

82READY

Sleep7h 12m

Steps5,993

Heart rate62 bpm

Your early-riser reward

20% off açaí bowls, today only.

Sahha

Permissions handled

Encrypted in transit

History backfilled

Background sync enabled

Cleaning · deduping · scoring

Raw data logs Biomarkers Scores Insights Archetypes Tags

Real-time webhooks

Always in sync

Query via API

Access controlled

Your service

Waiting for data…

On-device and permissioned

Readings are collected on the user’s own device, and only after they grant Apple Health or Health Connect permission. Nothing syncs without consent.

Every future device too

Permission is per data type, not per brand, so the watch a user buys next year arrives through the same integration with no extra prompt and no new code.

Your brand on the consent screen

The consent experience is configurable on both routes and names your product rather than Sahha. On providers that connect server to server you also register your own developer app, so the rate limits are yours alone.

Why Sahha

What a wearable integration usually costs you.

69
wearable providers behind one connection

One integration, not one per brand

Every vendor is its own project: its own API, its own OAuth, its own review process, its own rate limits and its own idea of what a sleep stage is. Ship two and you have written off everyone on a third. Sahha maintains 69 of them behind one connection and one schema, so adding the next brand is not a roadmap item.
- Apple Watchsame night
- Oura Ringsame night
- iPhonesame night
sleep_duration7:24h
Two devices, one number

Users who care about their health tend to own more than one device, and a watch and a ring will disagree about last night. Sahha reconciles them into a single daily value per biomarker so you are not writing tie-break logic. The raw records from every device stay available, so you can always audit which reading fed the number.
Work from the phone
30
Unlocked by a wearable
10

No wearable, no dead end

The device is optional, which matters on the day a user has not bought one yet. All 5 scores compute from the phone, so a profile exists from signup and connecting a wearable deepens it rather than creating it. That turns the device into something you can prompt for later instead of a gate on activation.

Sources

Whatever they are already wearing.

Most wearables arrive through the phone platforms

The wearables your users are most likely to own

69 wearable providers are integrated in total, far more than fit above. Most write to the phone platforms; the rest connect server to server through their own cloud. Every one is listed on its own page with the fields it delivers.

Browse all integrations

API reference

What changes when a wearable connects.

Every score returns the factors behind it, each with its own sub-score. This table is the honest answer to "how much does a wearable actually matter": for two of the five scores, not at all.

GET /api/v1/profile/score/{externalId}?types=readiness

{
  "id": "f04c8a71-2e59-4b16-9d83-6a25c7e0b431",
  "type": "readiness",
  "score": 68,
  "state": "medium",
  "factors": [
    { "name": "sleep_duration", "value": 7.4, "unit": "hour", "score": 0.88, "state": "high" },
    { "name": "sleep_debt", "value": 1.2, "unit": "hour", "score": 0.64, "state": "medium" },
    { "name": "walking_strain_capacity", "value": 0.72, "unit": "index", "score": 0.72, "state": "medium" }
  ],
  "scoreDateTime": "2026-08-12T00:00:00+12:00",
  "createdAtUtc": "2026-08-12T06:10:00Z"
}

The five scores, by factor availability 5

Score	Factors	Without a wearable	A wearable adds
Activity	6	6	None
Sleep	7	4	+3
Readiness	8	4	+4
Wellbeing	13	10	+3
Mental Wellbeing	6	6	None

Activity and Mental Wellbeing have full factor coverage from the phone. A wearable still improves them, but through precision rather than new factors: heart rate makes active energy a measurement instead of an estimate.

The biomarker family that only exists because of connected hardware. A phone can count steps and infer a sleep window; it cannot read a heart.

GET /api/v1/profile/biomarker/{externalId}?categories=vitals

{
  "id": "c73e1b28-6f40-4a95-8d21-5e0937ab61cf",
  "type": "heart_rate_resting",
  "category": "vitals",
  "value": "54",
  "valueType": "double",
  "unit": "bpm",
  "aggregation": "average",
  "periodicity": "daily",
  "startDateTime": "2026-08-11T00:00:00+12:00",
  "endDateTime": "2026-08-11T23:59:59+12:00",
  "createdAtUtc": "2026-08-12T06:10:00Z"
}

Vitals biomarkers and the hardware behind them 14

Field	What it measures	Device
heart_rate_resting	Heart rate at rest, the cleanest daily recovery signal	Wearable
heart_rate_sleep	Average heart rate through the night	Wearable
heart_rate_variability_sdnn	Beat-to-beat variation, SDNN	Wearable
heart_rate_variability_rmssd	Beat-to-beat variation, RMSSD	Wearable
respiratory_rate	Breaths per minute	Wearable
respiratory_rate_sleep	Breaths per minute through the night	Wearable
oxygen_saturation	Blood oxygen saturation	Wearable
oxygen_saturation_sleep	Blood oxygen saturation through the night	Wearable
vo2_max	Estimated maximal oxygen uptake	Wearable
skin_temperature_sleep	Skin temperature through the night	Wearable
body_temperature_basal	Basal body temperature	Thermometer
blood_glucose	Blood glucose concentration	CGM
blood_pressure_systolic	Systolic blood pressure	Blood pressure cuff
blood_pressure_diastolic	Diastolic blood pressure	Blood pressure cuff

Not every wearable reports every row. A basic tracker gives heart rate and little else, while a recovery-focused ring or watch covers most of this table.

Weekly and monthly behavioral classifications. Worth reading closely if you are deciding how much a wearable matters to your product, because almost none of them need one.

GET /api/v1/profile/archetypes/{externalId}

{
  "name": "activity_level",
  "value": "moderately_active",
  "dataType": "ordinal",
  "ordinality": 2,
  "periodicity": "weekly",
  "startDateTime": "2026-08-04T00:00:00+12:00",
  "endDateTime": "2026-08-10T23:59:59+12:00",
  "createdAtUtc": "2026-08-11T02:00:00Z"
}

Every archetype and its wearable requirement 14

Archetype	Type	Wearable
activity_level	Ordinal	Not required
exercise_frequency	Ordinal	Not required
primary_exercise	Categorical	Not required
primary_exercise_type	Categorical	Not required
secondary_exercise	Categorical	Not required
sleep_duration	Ordinal	Not required
sleep_regularity	Ordinal	Not required
sleep_quality	Ordinal	Not required
sleep_pattern	Categorical	Not required
bed_schedule	Ordinal	Not required
wake_schedule	Ordinal	Not required
mental_wellness	Ordinal	Not required
overall_wellness	Ordinal	Not required
sleep_efficiency	Ordinal	Required

13 of 14 classify from phone data alone. Archetypes need roughly two weeks of history before they stabilize, whichever device supplies it.

The raw samples underneath the daily values, each naming the device that recorded it. This is the layer where a wearable is most visibly different, because the phone has nothing comparable to send.

POST your webhook endpoint

[
  {
    "logType": "vitals",
    "dataType": "heart_rate",
    "externalId": "ext-908",
    "receivedAtUtc": "2026-08-11T09:15:00+00:00",
    "dataLogs": [
      {
        "id": "3a97f5d1-8c62-4e07-b419-2d5806fa7c3e",
        "parentId": null,
        "value": 61,
        "unit": "bpm",
        "source": "Apple Watch",
        "recordingMethod": "RECORDING_METHOD_AUTOMATICALLY_RECORDED",
        "startDateTime": "2026-08-11T09:14:00+12:00",
        "endDateTime": "2026-08-11T09:14:00+12:00",
        "additionalProperties": {}
      }
    ]
  }
]

REST API
Pull scores, biomarkers and archetypes per profile whenever your app asks.
Webhooks
New readings pushed to your endpoint as they land, so you never poll a device.
Mobile SDK
Read on device through Apple Health and Health Connect, or connect a vendor cloud server to server.

What you build

What one wearable integration lets you ship.

Support every device at once

Ship with 69 providers already integrated instead of picking two and apologizing to everyone else, and stop treating each new brand as a roadmap item.

Browse integrations

Onboard users who own nothing

Every user gets scores from the phone on day one, so activation never waits on hardware and a wearable becomes an upgrade prompt rather than a requirement.

Sahha Scores

Build on recovery signals

Resting heart rate, HRV and sleep stages are what recovery, strain and readiness features are made of, and they arrive normalized rather than per vendor.

Fitness API

Stop writing tie-break logic

A watch and a ring disagree about last night. Sahha returns one reconciled value per day per biomarker, with the raw records still there when you need to audit it.

Sahha Biomarkers

Go deeper on sleep

A phone gives you when someone slept and for how long. A wearable adds the stages, the interruptions and the recovery underneath it.

Sleep API

Compare against a population

Percentiles and trends need a cohort, not just one user history, which is the part you cannot build from a direct vendor integration.

Sahha Insights

How it compares

Three ways to read a wearable.

	Sahha Wearable API	Other wearable APIs	Build it yourself
Works with no wearable	30 of 40 factors
Wearable providers covered	69	Varies	One per build
Deduplicated across devices			On you
Scores and archetypes included		Sometimes, paid
Vendor accounts to maintain	Cloud sources only		Every one
Time to ship	Days	Weeks	Months

Other wearable APIs = device aggregators such as Terra, ROOK and Spike, which pipe vendor data but have no phone-only mode. The vendor accounts row is the one to read carefully: wearables reaching Sahha through Apple Health or Health Connect need nothing from you, while cloud integrations such as Garmin or Dexcom still require your own developer account with that vendor. Named, sourced comparisons are on the compare pages.

What building it yourself actually costs

FAQ

Questions that come up before you integrate.

What is a wearable API?

A wearable API is a single integration that reads health data out of many different wearables, so you do not build and maintain one integration per brand. Sahha integrates 69 wearable providers covering 600+ models and returns them on one schema along with scores, biomarkers and archetypes derived from that data rather than just the raw feed.

Does it work if my user has no wearable?

Yes, and this is the main thing that separates Sahha from a device aggregator. All five scores compute from smartphone data through Apple Health and Health Connect: 30 of the 40 score factors need no wearable, and 13 of 14 archetypes classify without one. Activity and Mental Wellbeing have full factor coverage from the phone alone.

What exactly does a wearable add?

Everything a phone reports, and then the layer a phone physically cannot sense. A wearable still supplies steps, distance, energy and sleep timing, usually more accurately, and adds the 14 vitals biomarkers, sleep stages, 10 further score factors and per-sample resolution through the night and through workouts. It turns behavioral observation into physiological measurement: a phone can tell you someone slept seven hours, a wearable can tell you whether that sleep was restorative.

Do I need my own API key for each wearable brand?

It depends which of the two routes a device takes. Wearables that write to Apple Health or Health Connect need nothing from you beyond the Sahha SDK and the user granting permission. Cloud integrations connect server to server and do require you to register your own developer account with that vendor and add the credentials once, after which Sahha handles the OAuth flow, the branded consent screen, backfill and normalization. Either way you write one integration, not one per brand.

What happens if a user wears two devices?

Sahha reconciles them into one value per biomarker per day, so a night recorded by both a watch and a ring is not counted twice and you never write tie-break logic. Reconciliation happens at the daily biomarker layer, so the raw records from every device stay available and you can always see which reading fed the number.

How quickly does wearable data arrive?

Data logs are delivered to your webhook as they arrive from the device. Scores and biomarkers are recalculated within about a minute of new data landing, and are delivered on a configurable interval that also acts as a deduplication window. New profiles receive up to 30 days of backfill on connect, so there is no cold start.

Is Sahha HIPAA and GDPR compliant?

Yes, and SOC 2. Health data is handled under all three, and the end-user consent screens are configurable to carry your brand rather than Sahha’s.

One integration, every wearable.

Support 69 wearable providers and 600+ models from a single connection, normalized to one schema.

Start building Book a demo

Free for 30 days · No credit card

69 wearable providers, 600+ models on one schema
Biomarkers, 5 scores and 14 archetypes, not a raw feed
Deduplicated across devices, with the raw records still available
HIPAA, GDPR and SOC 2, with your brand on the consent screen

One integration for every wearable your users own.

Every reading, as the device sends it

The vitals a phone cannot sense

The factors a wearable fills in

Behavior, classified weekly

Resting heart rate against a cohort

What no wearable can see