How to Add Wearable Data to a Corporate Wellness Platform

Key Takeaways

• Corporate wellness platforms need wearable data from multiple providers without asking employees to switch devices. The integration layer has to be device-agnostic from day one.
• Open Wearables connects wearable providers through a single API. A Garmin user and a Whoop user in the same company connect through the same OAuth flow and appear in the same data model.
• Health scores are computed from raw provider data and exposed through the health scores API. Available categories include sleep, recovery, readiness, activity, stress, resilience, and more.
• Employee data stays on your infrastructure. Open Wearables is self-hosted: no third-party cloud has access to your employees' health data.
• What you build on top (dashboards, aggregated reporting, coaching prompts, trigger-based notifications) is your application layer. Open Wearables provides the data foundation and health intelligence on top.

Adding wearable support to a corporate wellness platform sounds straightforward until you account for the device landscape. Your employees use Garmin, Whoop, Oura, Apple Watch, Polar, Fitbit, and more. Each provider has its own OAuth flow, its own data schema, and its own sync model. Building direct integrations with each is months of work per provider. Building one abstraction layer is a different kind of project.

This article covers what Open Wearables provides for corporate wellness use cases, what the integration looks like architecturally, and what you need to build on top.

The Device Problem

Corporate wellness platforms that require a specific device have poor adoption. Employees already have the devices they prefer. The platform needs to meet them there.

Open Wearables handles OAuth authorization and data normalization for each supported provider. An employee with a Garmin connects through a Garmin OAuth flow. An employee with Whoop connects through a Whoop OAuth flow. Both land in the same normalized data model in your instance. Your application queries one API regardless of which device an employee uses.

The current list of supported providers is at docs.openwearables.io/provider-setup. For providers not yet in the community version, Momentum can build custom integrations as a commercial service.

What Data Is Available

Open Wearables normalizes provider data into consistent types. For a corporate wellness context, the most relevant are:

• Daily activity aggregates (ActivitySummary): steps, distance, active calories, active minutes, sedentary minutes, intensity minutes (light, moderate, vigorous), and daily heart rate stats.
• Sleep sessions (SleepSession): sleep start and end time, total duration, sleep efficiency, sleep stages (light, deep, REM, awake), and a flag distinguishing naps from main sleep sessions.
• Workouts (Workout): activity type, duration, distance, calories, average and max heart rate.

Health scores are computed from raw provider data and exposed through the health scores API. Not every score is available from every provider. The source field on each record identifies which provider contributed the underlying data. The full list of available score categories is at docs.openwearables.io.

Architecture: What Open Wearables Handles

When an employee connects their wearable through your platform, the flow is:

1. Your application redirects to the Open Wearables authorize endpoint for the relevant provider
2. The employee authenticates with their provider account (Garmin Connect, Whoop app, Oura cloud, etc.)
3. Open Wearables receives the OAuth callback, stores the connection, and begins syncing data
4. Provider data arrives via webhook (Garmin, Whoop, Oura) or scheduled polling (Polar, Fitbit) and is normalized into your PostgreSQL instance
5. Your application queries the Open Wearables REST API for employee health data

Open Wearables handles: OAuth flows for each provider, token storage and refresh, webhook registration and processing, data normalization to consistent field names and units, and within-provider deduplication.

Your application handles: the authorization trigger, employee identity mapping (linking Open Wearables user IDs to your employee records), data querying, dashboard rendering, aggregated reporting, and any notification or coaching logic.

Data Ownership and Compliance

Employee health data is sensitive. In a corporate wellness context, the question of where data lives and who has access to it matters for compliance and employee trust.

Open Wearables is self-hosted. Employee wearable data flows into your PostgreSQL instance on your infrastructure.

For HIPAA-eligible deployments or enterprise-grade configurations, Momentum offers commercial services including BAAs. Details at openwearables.io/pricing.

What You Build on Top

Open Wearables provides the data layer. The wellness experience is what your application builds on top of it.

• Aggregated team dashboards: query activity summaries and sleep data across your employee population. Average steps per department, sleep duration trends, activity distribution. Open Wearables returns data per user; your application aggregates.
• Individual employee views: each employee's connected devices, daily metrics, sleep trends over time. The data is queryable by user ID and date range.
• Trigger-based notifications: define logic in your application and query the Open Wearables API on a schedule. Outbound webhooks (push notifications from Open Wearables to your backend when new data arrives) are on the roadmap. Check the GitHub repository for current status.
• AI-powered coaching prompts: the Open Wearables MCP server gives any LLM structured access to health data. You define the domain logic: for corporate wellness, that means focusing on stress, sleep, and energy rather than athletic performance metrics, and framing recommendations in terms of sustainable habits rather than optimization.

Related articles

• How to Give Your LLM Access to Wearable Data
• How to Handle OAuth, Webhooks, and Token Refresh Across Multiple Wearable Providers
• How to Build a HIPAA-Compliant Health App That Uses Wearable Data
• Wearable Data Deduplication: How to Handle Users With Multiple Devices

FAQ

Can employees use any wearable device?

They can use any device that is supported by Open Wearables. The current list of supported providers is at docs.openwearables.io/provider-setup. For providers not yet supported, custom integrations are available through Momentum. Employees who use unsupported devices cannot be onboarded until support is added.

Do employees need to create new accounts?

No. Employees connect their existing provider accounts through the OAuth flow. They log in with their Garmin Connect account, their Oura account, their Whoop account. No new account creation is required on the provider side.

How do we handle employees who do not want to share health data?

Open Wearables requires explicit OAuth authorization per employee. An employee who does not authorize the connection has no data in your instance. The authorization is voluntary and revocable. Your platform's consent and opt-out handling is application-level logic.

Can we aggregate data across the whole company without exposing individual records?

Yes. You query individual employee data through the Open Wearables API (per user ID) and aggregate it in your application layer. Open Wearables does not expose population-level aggregate endpoints; that aggregation logic lives in your application.

What health scores are available for corporate wellness?

Health scores are computed from raw provider data. Not every category is available from every provider. The full list of available score categories is at docs.openwearables.io. Score availability depends on which providers employees have connected.