---
title: "Wearable Data for Employee Wellness Apps"
description: "The open-source wearable data layer under your employee wellness app. Member data stays in your own cloud account, in the region you chose."
canonical_url: "https://openwearables.io/for/employer-wellness"
---

# The data layer under your wellness programme.

Employer wellness

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.

[Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book?tier=pro)

Built on Open Wearables

- Heart Monitor logo
- Hundred logo
- JustGains logo
- Lifelong logo
- MoveTogether logo
- Suna logo
- Yoboo logo

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.

[Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book?tier=pro)

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](https://openwearables.io/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 employer's quarterly wellbeing report from members on five kinds of device, and the aggregate PDF sent to HR.

### 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 team step challenge in week four: three teams on a leaderboard, 82% of members still active, every step synced from the member's own device.

### A member view

What one person sees about their own trends, under your brand, computed inside your deployment from the member's own data.

A member's week in a branded app: a recovery score of 74, the nights behind it, and how the score is calculated.

## 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.

[Browse 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)
- [SensorBio integration](https://openwearables.io/integrations/sensorbio)
- [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 the providers connected and validated on real accounts.

[Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book?tier=pro)

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](https://openwearables.io/sub-processors) 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](https://openwearables.io/case-study/heart-monitor) 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.