SensorBio integrationSensorBio data, in your own cloud
One API for SensorBio and for the rest of the wearables your users own, connected through SensorBio's own API and returned in a single schema. Self-hosted in a cloud account you control, under an MIT licence.
Built on Open Wearables
Data coverage
SensorBio data we support
Readings arrive as a continuous stream of timestamped samples, and everything below lands in the same schema as every other source.
Sleep
Deep, light, REM and awake time, with a stage timeline per session.
Heart rate
Continuous samples, plus resting heart rate.
Heart rate variability
RMSSD, sampled continuously and as a resting value.
Blood oxygen
SpO2 samples through the day and night.
Respiratory rate
Breaths per minute, sampled continuously.
Workouts
Type, duration, heart rate, energy and distance.
Steps and distance
Daily totals for every day synced.
Calories
Active and resting energy, split out per day.
SensorBio scores
SensorBio's own daily sleep, recovery and activity scores.
What working with Open Wearables gives you
Two views of the same deployment. One for the people wiring it in, one for the people signing it off.
One schema, not one per provider
SensorBio arrives in the same shape as every other source, so your code carries no SensorBio-specific branches and adding a source later does not change the call.
- Sleep
- Heart rate
- HRV
- SpO2
A continuous stream, paged for you
SensorBio returns heart rate, HRV, blood oxygen and respiratory rate as a stream of timestamped samples. Open Wearables pages through it with a cursor and writes each sample to the same series your other sources fill.
- Cursor paging
- Timestamped samples
Polling, already scheduled
The SensorBio API is read over REST with no webhooks, so Open Wearables polls it hourly by default and refreshes tokens along the way. Requests go over HTTP/2, which the API requires, so there is nothing for you to schedule or configure.
- Hourly polling
- OAuth 2.0
Health scores computed in your deployment
SensorBio's own sleep, recovery and activity scores arrive as data, as SensorBio calculates them. Health scores from our science team run alongside them inside your deployment, validated before release, and are part of Pro.
- SensorBio scores
- Health scores
Access you control
It runs in your cloud account, under your credentials. When we work on your system, we do it under a DPA you sign.
- Your credentials
- Your region
The SensorBio relationship stays yours
Credentials issued in your name, data going straight from SensorBio into your account.
- Your developer account
- Your credentials
Costs you can see
Running it costs your own cloud bill, paid to your provider. Deployment and Integration are one-off services, and health scores and the other licensed modules come with Pro.
- Your cloud bill
- One-off services
No dependency on us
MIT licence, full source, public roadmap and public issues, plus community support on Discord.
- MIT license
- Full source
- Discord
How it works
From nothing to your first SensorBio query
- 01
Bring it up
Clone the repository and run it with Docker Compose. First API call in five minutes, before any provider is connected.
Terminal
git clone https://github.com/the-momentum/open-wearables.git cd open-wearables && docker compose up -d - 02
Get SensorBio API access
Ask SensorBio for a developer account with API access, then register your redirect URI in their developer portal. The client ID and secret are issued in your name, so the data relationship is between you and SensorBio.
SensorBio API setup guide - 03
Connect a user
Your user authorises through SensorBio's own consent screen. Open Wearables handles the token lifecycle from there, including the refresh that keeps the connection alive months later.
- 04
Query the user, not the provider
SensorBio data arrives in the same schema as every other source, in your own database, so your application code carries no SensorBio-specific branches.
The honest comparison
Hosted SaaS API, in-house build, or self-hosted
Where each one actually wins. If a hosted API fits your situation, use one.
| Hosted SaaS API | Build in-house | Open Wearables, self-hosted | |
|---|---|---|---|
| [01] SensorBio credentials | Theirs, if they support it | Yours to obtain | Yours, in your own name |
| [02] Sync model | Handled for you | Polling you build and schedule | Hourly polling, already scheduled |
| [03] The continuous stream | Mapped to their schema | Cursor paging you write and maintain | Paged and split into the series every source fills |
| [04] Where SensorBio data sits | Their cloud, their regions | Yours | Your cloud account, your region |
| [05] The data model | Theirs, you build against their schema | Yours | Yours, in your database |
| [06] SensorBio API changes | They absorb them | Your team tracks and adapts | Fixed in a release you pull |
| [07] Cost shape | Scales with monthly active users | Salaries and infrastructure | Fixed, flattens as you grow |
What stays yours
The deployment, the data and what you build on it stay in your account, whoever runs it
Sovereignty
SensorBio data goes straight to your cloud, with no aggregator in between.
Residency
It stays in the region you chose, provable by pointing at an account.
Control
What you build on top of Open Wearables is yours, and the schema and the data are in your account.
Your own reasons
No regulator forcing it. You want the data in your own account anyway.
SensorBio is one integration in the same API
You query a user rather than a provider, so somebody who wears SensorBio and also trains with a watch or logs runs on Strava comes back in one shape, under one user.
Deploy Open Wearables in your own cloud
The repository is public and the deployment is yours from the first commit. Start from the source, or bring us in to stand it up in your account with SensorBio connected and validated on real accounts.
FAQ
Do you have more questions?
Does SensorBio have an API?
Yes. It uses OAuth 2.0, and you need a SensorBio developer account with API access to get a client ID and secret. The credentials are issued in your name, so the data relationship is between you and SensorBio.
What does SensorBio actually give us?
Sleep with a stage timeline, workouts, and a continuous stream of heart rate, HRV, blood oxygen and respiratory rate, plus resting heart rate, daily steps, distance and calories, and SensorBio's own daily scores. Everything arrives in the same schema as your other sources.
Do we get SensorBio's own scores?
Yes. Its daily sleep, recovery and activity scores arrive as SensorBio calculates them, alongside the data underneath.
Is the HRV comparable with our other sources?
Yes. SensorBio's HRV arrives as RMSSD, the same measure Oura, Polar, Ultrahuman and Whoop report, so it lands in the same series and can be read side by side.
Does it support webhooks?
No. The SensorBio API is read over REST, so Open Wearables polls it hourly by default. New data lands within the hour rather than the second, which is the trade-off the API imposes.
Does SensorBio tell naps apart from night sleep?
Not through the API. A day can return more than one sleep session, and each arrives as its own record, so Open Wearables stores every session as sleep rather than guessing a nap from its length.
How far back does a first sync go?
Ninety days by default when a user connects. You can switch that off and request a specific range yourself, up to a year back.
What do we need to configure?
Your client credentials from SensorBio and a redirect URI registered in their developer portal. The setup guide in the docs has the exact variables.
Can we combine SensorBio with other sources?
Yes. SensorBio sits alongside whatever else a user connects, and you query the user rather than each provider, so a second source never means a second code path.