Why teams move from a hosted wearable API to Open Wearables
Key takeaways
- A hosted wearable API is a sensible way to start: someone else runs it, and the provider approvals are already in place.
- As wearable data becomes the foundation of a product, teams want the provider apps in their name, the data in their own cloud and the schema in their own database. Open Wearables is built for that.
- Four things push teams to move now: provider terms that expect your own app, enterprise security reviews, residency requirements, and the need to control change.
- After the move, your product reads one standard schema from your own deployment, and the provider relationships are yours. In exchange, you run the deployment or have it run for you in your account, and users reconnect once.
- If speed matters more than control and nobody is asking where the data sits, a hosted API is still a reasonable choice. If that is changing, Momentum can help you move.
A hosted API is a good way to start
Most teams that read wearable data started with a hosted API, and for good reasons. One integration covers many devices, the provider approvals are already in place, and someone else keeps the connections running. For a product finding its feet, that speed is worth a lot.
The trade-offs show up later, as the product grows. Wearable data stops being a feature and becomes the layer that coaching, care programmes, insurer and employer products are built on. Then the questions change: whose provider apps are these, whose cloud does the data sit in, and what happens when either of those has to change?
Two architectures, side by side
With a hosted wearable API, data flows from each provider through the vendor's infrastructure before it reaches your product. The provider apps are registered to the vendor, the data sits on the vendor's schema, and their team operates the service.
With Open Wearables, the same providers connect inside a cloud account you own. Open Wearables is an open-source platform for wearable and health data, MIT licensed and built by Momentum. It connects to the devices your users already own, standardises what comes back into one schema, and runs inside your own account rather than ours.
- Where the data sits: Hosted wearable API: the vendor's cloud. Open Wearables: your account, your region.
- Who operates it: Hosted wearable API: the vendor. Open Wearables: you, or we run it in your account.
- Whose provider apps: Hosted wearable API: the vendor's. Open Wearables: yours, registered in your name.
- The data model: Hosted wearable API: the vendor's schema. Open Wearables: one standard schema in your own database.
- Time to first data: Hosted wearable API: minutes, on their infrastructure. Open Wearables: minutes locally, then a deployment.
- Leaving later: Hosted wearable API: you rebuild on somebody else's model. Open Wearables: already yours.
Neither column wins every row. A hosted API reaches working data faster. Open Wearables gives you the layer itself.
What your product gets after the move
One schema, in your own database. Activity, sleep, heart rate and body measurements come back in the same shape whichever device produced them. Your product queries the user, not the provider.
The raw payloads, if you want them. The original provider payload can be kept underneath the standard schema, so anything can be re-derived later without going back to the provider.
Every way in, from one deployment. Cloud providers connect server to server under your credentials. Apple Health, Health Connect and Samsung Health sync from the phone through the mobile SDK. Your product reads it all over the REST API, reacts to webhooks, or lets an AI assistant ask questions through the MCP server.
Health scores where you need them. With Pro, health scores designed and validated by our science team are computed inside your deployment, next to the data they come from.
Code you can read. The source, the roadmap and the issues are public. We are working toward Open Wearables 1.0, and the roadmap shows what is live and what is still being built.
Why teams make the move now
Provider terms expect your own app
Device makers increasingly want a direct relationship with the company that builds the product. Garmin's reopened developer program expects each company to register its own app and hold its own credentials, and its agreement does not allow passing keys or data to a third party without written permission. Strava's API agreement carries a similar rule on API tokens. With Open Wearables, the provider apps are registered in your name, so the relationship is yours.
Security reviews ask where the data sits
Enterprise customers, insurers and care providers send security questionnaires before they sign, and the questions are consistent: where is member data stored, who can reach it, and what happens on a bad day. When Open Wearables runs in your own cloud account, behind the network rules and monitoring you already have, the answers are about your environment. When Momentum works on your system, it does so under a DPA you sign.
Some markets set residency rules
Some contracts and regulators require health data to stay inside a country or region. Your Open Wearables deployment runs in the region you choose, and you can evidence it by pointing at your own cloud account rather than at a vendor's policy page.
Teams want to control change
Providers change their APIs, their algorithms and their terms. With your own deployment, you decide when to upgrade, test changes in staging first, and see fixes for provider changes land in the public repository. Your history sits in your own database rather than behind someone else's retention window, which matters when a feature you build next year has to run on data you collected this year.
What the move asks of you
It is worth being plain about the trade-offs. You need provider credentials in your own name, and approval takes longer with some providers than others. You run the deployment yourself, or pay someone to run it in your account, so infrastructure, monitoring and upgrades become someone's job. And your users reconnect once, because their existing connections belong to the hosted service's apps.
If speed matters more than control and nobody is asking where your data sits, a hosted API is still a reasonable choice. If either of those is changing, moving early usually means fewer hard conversations later.
How the move works
Moving from a hosted API to Open Wearables is usually a re-integration rather than a data migration. Your history stays where it is, new data lands in your own deployment from the switch onwards, and most teams run both side by side before cutting over. The full sequence, from the architecture audit to switching off the hosted API, is in our migration playbook, and the migration page shows how a move runs.
How Momentum supports the move
You can move to Open Wearables entirely on your own, with the documentation and the community on Discord. When a launch date, an enterprise customer or the size of your user base makes that harder, Momentum, the team that builds Open Wearables, offers:
- Deployment: production and staging in your cloud and region, providers onboarded under your credentials, infrastructure as code in your repository.
- Integration: the connection and consent flow built into your app, tested end to end.
- Enterprise support: an SLA, a named on-call, provider changes handled and upgrades tested in staging first.
- Custom development: a migration off a hosted API planned and run with your team, new sources, and AI or coaching features on top.
Whichever you choose, the deployment and the data stay in your account.
FAQ
Is there a hosted version of Open Wearables?
No. You host it in your own cloud account, or we run it there for you. That is the design rather than a gap: the reason teams move is that the data stops passing through a vendor's cloud.
Will our users notice the move?
Once. Each user reconnects their device to your app, because their existing connection belongs to the hosted service. Planned well, it is a single tap in your product.
What do we need to run Open Wearables?
If you can run a PostgreSQL database and deploy Docker containers, you can run it. It deploys with Docker Compose to start and infrastructure as code for production.
What happens if Open Wearables stops being maintained?
You keep everything. The code is MIT licensed and the deployment is in your account, which is a different position from a hosted service shutting down.
Can we move one provider at a time?
Yes. Many teams start with the providers their users connect most, and move the rest once the first ones are proven.
Open Wearables
Open Wearables is an open-source platform that connects your application to wearable and health data providers through a single API. One normalized data model, multi-provider support in a single self-hosted deployment, MIT licensed, and health intelligence built in: normalized recovery, sleep, activity and biometric data ready for your product layer.
We offer custom deployment and integration support through Momentum. If your team needs help getting to production faster, we can set up and configure Open Wearables as part of a managed engagement. Let's talk.
Book a demo to see how Open Wearables fits your use case.