--- title: "SensorBio API | Self-Hosted" description: "Connect the SensorBio API and keep the data in your own cloud account. Sleep stages, workouts, 24/7 heart rate, HRV and SpO2, MIT licensed." canonical_url: "https://openwearables.io/integrations/sensorbio" --- # SensorBio data, in your own cloud SensorBio integration 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. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) Built on Open Wearables - Heart Monitor logo - Hundred logo - JustGains logo - Lifelong logo - MoveTogether logo - Suna logo - Yoboo logo 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 [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) 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](https://openwearables.io/docs/providers/sensorbio-api-integration) 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. [Browse all integrations](https://openwearables.io/integrations) - [Garmin integration](https://openwearables.io/integrations/garmin) - [Whoop integration](https://openwearables.io/integrations/whoop) - [Oura integration](https://openwearables.io/integrations/oura) - [Polar integration](https://openwearables.io/integrations/polar) - [Suunto integration](https://openwearables.io/integrations/suunto) - [Withings integration](https://openwearables.io/integrations/withings) - [Strava integration](https://openwearables.io/integrations/strava) - [Ultrahuman integration](https://openwearables.io/integrations/ultrahuman) - [Google Health API integration](https://openwearables.io/integrations/google-health) - [Fitbit integration](https://openwearables.io/integrations/fitbit) - [Apple Health integration](https://openwearables.io/integrations/apple-health) - [Google Health Connect integration](https://openwearables.io/integrations/google-health-connect) - [Samsung Health integration](https://openwearables.io/integrations/samsung-health) - [Garmin integration](https://openwearables.io/integrations/garmin) - [Whoop integration](https://openwearables.io/integrations/whoop) - [Oura integration](https://openwearables.io/integrations/oura) - [Polar integration](https://openwearables.io/integrations/polar) - [Suunto integration](https://openwearables.io/integrations/suunto) - [Withings integration](https://openwearables.io/integrations/withings) - [Strava integration](https://openwearables.io/integrations/strava) - [Ultrahuman integration](https://openwearables.io/integrations/ultrahuman) - [Google Health API integration](https://openwearables.io/integrations/google-health) - [Fitbit integration](https://openwearables.io/integrations/fitbit) - [Apple Health integration](https://openwearables.io/integrations/apple-health) - [Google Health Connect integration](https://openwearables.io/integrations/google-health-connect) - [Samsung Health integration](https://openwearables.io/integrations/samsung-health) ## 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. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) 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](https://openwearables.io/docs/providers/sensorbio-api-integration) 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.