The data layer under your wellness programme.
Open Wearables connects the devices your members already wear and returns their activity, sleep and heart rate in one schema, so your programme works the same whichever watch or ring somebody chose.
Built on Open Wearables
What you get
What Open Wearables gives a wellness platform.
Every question an employer asks about member data ends up as a question about your vendors. Open Wearables keeps the wearable layer inside your own account.
Access you control.
It runs in your cloud account, under your credentials, so member data does not reach a vendor tenant. When we work on your system, we do it under a DPA you sign.
- Your account
One schema, one population.
Query a member, not a provider. Whatever device somebody chose, the metric arrives in the same shape, so a cohort report does not depend on who wears what.
- One schema
- Any device
- Time series
Know the moment it happens.
A webhook fires when new steps, a workout or a night of sleep arrives, and when a member disconnects a device, so leaderboards update themselves and nobody drops out unnoticed.
- steps.created
- connection.revoked
Your region, provably.
You choose where it runs when it is deployed. Where member data sits becomes a fact you can show rather than a clause you negotiate per client.
- Your region
- eu-central-1
Credentials in your name.
Each source issues developer credentials to your organisation, so the data relationship sits between you and them.
- Your credentials
- Provider apps in your name
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
How it works
From decision to first cohort.
- 01
Deploy it.
Production and staging in your own cloud account, in the region you choose, defined as infrastructure code in your repository. Either your team stands it up, or you buy a deployment and we do it inside your account.
- 02
Get your own provider credentials.
Each source issues developer credentials in your name, and you apply for them directly. Approval timelines vary and this is the slowest step, so it starts on day one.
- 03
Enrol members.
Members authorise through each provider's own consent screen, inside your interface, so what they agreed to is recorded in your product rather than somebody else's.
- 04
Query the population.
Standardised data lands in your own database, so a cohort report for an employer is a query rather than an export you wait for.
See pricing
The honest comparison
Hosted API, in-house, or self-hosted.
Where each one wins. If a hosted API fits your situation, use one.
| Hosted SaaS API | Build in-house | Open Wearables | |
|---|---|---|---|
| [01] First API call | Hours | Months | Minutes, with Docker Compose |
| [02] Who can reach the data | The vendor and its sub-processors | Your team | Your team, and us under a DPA you sign when we work on it |
| [03] Where member data sits | Their cloud, their regions | Yours | Your cloud account, your region |
| [04] The data model | Theirs. You build against their schema | Yours | Yours, in your database |
| [05] Raw provider payloads | Varies by vendor | Whatever you keep | Kept in your own bucket when you turn it on |
| [06] Provider credentials | Theirs, handled for you | Yours to obtain | Yours, in your own name |
| [07] Certifications | Theirs | Yours to earn | Yours, in your certified environment |
| [08] Cost shape | Scales with monthly active users | Salaries and infrastructure | Fixed. Flattens as you grow |
What stays yours
The deployment, the data and the algorithms stay in your account, whoever runs it.
Sovereignty
Member data does not sit in a third party's cloud.
Residency
It stays in the region you chose, provable by pointing at an account.
Control
You decide who reaches member data, under your own credentials. What you build on top of Open Wearables is yours.
Your own reasons
Before a client's procurement asks, the schema and the data are in your account.
Who it is for
The platforms this fits.
This page is written for the team building the programme, not for the employer buying one. These are the shapes where owning the data layer changes the deal.
Employer wellness vendors
You are a processor for the employer, so their governance questions land on your desk and your vendor list is part of the answer.
Benefits and insurance platforms
Wearable data next to the benefits record you already hold, where the client is regulated and the review is thorough.
Occupational health providers
Health data about somebody's workforce, where who can reach it is the first question anybody asks.
Wellbeing and engagement apps sold to companies
Consumer-grade product, enterprise-grade procurement, and a security questionnaire that arrives before the contract.
What you can build
What teams build on it.
Data arrives on its own from whatever device each person owns, so nobody has to log anything.
A cohort report
The same metric across a client's population, computed in your own database, so what you show the employer does not depend on a vendor's export schedule.
An engagement layer
Streaks, team challenges and a weekly recap running on data that arrives on its own, which is what keeps a programme alive past week three.
A member view
What one person sees about their own trends, under your brand, computed inside your deployment from the member's own data.
Whatever your members wear, they can join.
Each connected source arrives in the same schema, so a report or a challenge reads the same whichever device somebody chose.
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 the providers connected and validated on real accounts.
FAQ
Do you have more questions?
Is this an employee wellness app we can roll out to our staff?
No. Open Wearables is the wearable data layer that those apps are built on, so it belongs one level below the product your employees would open. If you are an employer comparing wellness apps, you want one of our customers rather than us. If you build the app, this is the part that connects the devices and standardises what comes back.
Our HR client asks where member data lives. What do we tell them?
The cloud account and region you chose at deployment, which you can point at rather than describe. Member data does not pass through a vendor tenant. When we work on your system, we do it under a DPA you sign.
We are a processor for the employer. Who can reach member data?
Your team. It runs in your cloud account, under your credentials, so member data does not reach a vendor tenant. When we work on your system, we do it under a DPA you sign. The sub-processors page covers both.
Can members use whatever device they already own?
That is the normal case. Whatever somebody chose, the metric arrives in the same shape, so a cohort report does not depend on standardising the population onto one brand.
Can we see individual data, or only aggregates?
That is your decision to make and to defend, because the data sits in your database and the access rules are yours to set. Most programmes separate what the member sees from what the employer sees, and the architecture here does not force either shape on you.
Do you hold SOC 2 or ISO 27001?
No. The deployment runs inside your certified environment, which is how most platforms answer this in their own audit.
Will you sign a DPA?
Yes, whenever our people can reach your deployment: under Pro support, during a Deployment or Integration service, and for as long as Enterprise runs. Where you self-host on Core, there is no processing for us to agree to, because we never touch it.
We already use a hosted aggregator. How hard is moving?
Usually a re-integration rather than a data migration. Your historical data stays where it is, and what changes is where new data lands from the switch onwards. Most teams run both in parallel while they validate, then cut over.
Is it running in production anywhere?
Yes. Heart Monitor runs Open Wearables in production at around 90,000 monthly active users, and their own engineer did the integration in a week. The case study has the stack and the timeline.
Who maintains Open Wearables?
Momentum, a healthcare software development company. The project is MIT licensed and developed in the open, with a public roadmap and public issues, so the source does not depend on us continuing to fund it.