How to Add Wearable Support to an Existing Health App in Days, Not Months

Open Wearables Team · July 22, 2026 · 5 min read

Key Takeaways

Adding wearable support to an existing app does not require rebuilding your data layer. Open Wearables sits alongside your existing backend and exposes a REST API your application calls.
The Docker Compose stack deploys in minutes. Full integration including OAuth setup with providers and end-to-end testing typically takes 1-2 weeks.
Provider credential approval is the longest step and the most variable. Most providers are self-service. Garmin's developer program is currently not accepting new applications.
If you already have Garmin or Apple Health integrated directly, you can still use Open Wearables for additional providers, the unified data model, deduplication, and the health intelligence layer.
Open Wearables works alongside existing integrations. You do not need a full cut-over to start using it.

Most health apps start with one wearable integration. A user requests Garmin support. You build it. Three months later, another user wants Whoop. You build that too. By the time you have four providers integrated, you have four separate OAuth implementations, four normalization layers, and four sync architectures to maintain.

The question is not whether to add wearable support. It is whether to keep building each provider separately or to replace that approach with a single layer that handles them all.

What the Integration Actually Looks Like

Open Wearables is a self-hosted service that runs alongside your existing backend. It does not replace your application. It adds a data layer that your application calls.

Your application redirects users to Open Wearables to connect their wearable device. Open Wearables handles the OAuth flow, token storage, and ongoing data sync. Your application queries the Open Wearables REST API for normalized health data. The data appears in consistent format regardless of which device the user has.

Your existing application logic, your existing database, your existing user management: none of that changes. You add a service dependency and a set of API calls.

Timeline: What Takes How Long

From the Open Wearables documentation:

Docker setup: minutes. Clone the repository, copy .env.example to .env, run docker compose up -d, run make init. The developer portal is at localhost:3000. The API is at localhost:8000.
Provider credential setup: 1-4 weeks depending on provider. This is the step that determines your actual timeline. Most providers (Strava, Polar, Oura, Whoop, Fitbit) are self-service and issue credentials immediately. Garmin's developer program is currently not accepting new applications.
Integration into your application: depends on your architecture. You need to add the authorize redirect and API calls to fetch health data. For a standard web application with a backend, this is typically a few days of work.
End-to-end testing: a few days. Connect test accounts for each provider, verify data is syncing correctly, test edge cases.

Total realistic timeline: 1-2 weeks for teams with existing infrastructure, excluding provider approval delays.

If You Already Have Direct Provider Integrations

If your application already has Garmin or Apple Health integrated directly, you do not need to replace those integrations to use Open Wearables. You can deploy Open Wearables for new providers while keeping existing direct integrations in place. The two approaches run in parallel.

If you already support Garmin directly, you can add Open Wearables to handle Suunto, Polar, Whoop, Oura, and others without touching your existing Garmin implementation. You can also use Open Wearables for its unified data model and deduplication layer even if you migrate Garmin to it later.

The practical approach: keep what is working. Add Open Wearables where it solves a real problem. Migrate the rest when it makes sense.

Web-Only vs. Mobile Applications

For most providers (Garmin, Polar, Suunto, Strava, Oura, Whoop, Fitbit), the OAuth flow works through a web redirect. Your backend initiates the authorization, the user authenticates on the provider's website, and data starts syncing. No mobile SDK required.

Apple Health is the exception. Apple does not expose a backend API for HealthKit data. To support Apple Health users, your application needs an iOS component that reads from HealthKit on-device and sends data to your Open Wearables instance. Open Wearables ships a Flutter SDK for this. A React Native SDK is on the roadmap.

Google Health Connect and Samsung Health are similarly SDK-based on Android.

If your application is web-only and you need Apple Health support, you need a companion mobile app that reads from HealthKit and sends data to your Open Wearables instance.

What to Query Once It Is Running

Once Open Wearables is deployed and users have connected their devices, you query the REST API directly from your backend:

            # Get workouts for a user
curl -H "X-API-Key: YOUR_API_KEY" \
  "http://localhost:8000/api/v1/users/USER_ID/events/workouts"

# Get sleep sessions
curl -H "X-API-Key: YOUR_API_KEY" \
  "http://localhost:8000/api/v1/users/USER_ID/events/sleep"

# Get daily activity summary
curl -H "X-API-Key: YOUR_API_KEY" \
  "http://localhost:8000/api/v1/users/USER_ID/summaries/activity"

The response format is the same regardless of which provider the user has connected. A workout from Garmin and a workout from Polar use the same field names, the same units, the same timestamp format.

FAQ

Do I need to rebuild my existing backend to use Open Wearables?

No. Open Wearables is a separate service that runs alongside your existing backend. You add API calls to query it. Your existing data model, authentication, and business logic stay in place.

Can I use Open Wearables if my app is already live in production?

Yes. You deploy Open Wearables on your infrastructure, configure provider credentials, and start routing new wearable connections through it. Existing users are not affected until you migrate them, which you can do gradually.

What if I only need one provider?

Open Wearables makes sense even for a single provider if you anticipate adding more in the future, if you want the normalized data model, or if you plan to build health intelligence features on top of the data. If you only ever need one provider and have no plans to expand, a direct integration may be simpler.

How do I map Open Wearables users to my existing users?

Open Wearables manages its own user model. You link Open Wearables user IDs to your application's user IDs in your own database. When a user connects a wearable through your application, you create an Open Wearables user (or use an existing one) and store the mapping. All subsequent queries use the Open Wearables user ID.

What support is available during integration?

Community support through Discord and GitHub Issues. For hands-on implementation help, Momentum offers commercial services. Details at openwearables.io/pricing.

Back to all posts