The data layer under your training and nutrition product.
Open Wearables connects the watches and rings your customers already wear, so every plan and recommendation your brand makes starts from how they actually trained, slept and recovered.
Built on Open Wearables
What you get
What Open Wearables gives a brand team.
Wearable data arrives in a different shape from every device. Open Wearables evens that out, so whatever your product recommends, a meal, a supplement or a session, your team can explain it.
Know when a session lands.
A webhook fires when a workout or a night of sleep arrives, so a plan can change the moment a session syncs rather than the next morning.
- workout.created
- sleep.created
One schema, any device.
Query a customer, not a provider. Whatever watch or ring somebody chose, workouts, sleep and recovery arrive in the same shape.
- One schema
- Any device
- Time series
Data without the logging.
Readings arrive in the background from the device somebody already wears, so personalisation does not depend on anybody remembering to log a session.
- Background sync
- No manual entry
History that follows the customer.
When somebody swaps a watch for a ring, their history stays in your database and the new device lands in the same schema, so the plan keeps learning from one timeline.
- Device switch
- One timeline
Your region, provably.
You choose where it runs when it is deployed, which settles most of what a retail or enterprise partner asks about customer data.
- Your region
- eu-central-1
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 recommendation.
- 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
Connect the watch.
Customers authorise through each provider's own consent screen, inside your app. The mobile SDK handles on-device sources in the background, behind the login you already have.
- 04
Personalise on real data.
Workouts, sleep and recovery land in your own database, so the meal plan, the supplement or the session is computed from what actually happened rather than from a questionnaire somebody filled in once.
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] The scoring logic | Proprietary, not published | Build and validate it yourself | Designed and validated by our science team, licensed as a module |
| [03] Where customer 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] Leaving later | You built on their data model | Not applicable | Already yours |
| [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
Customer 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 athlete data, under your own credentials. What you build on top of Open Wearables is yours.
Your own reasons
Before a partner or a regulator asks, the data model and the data sit in your account.
Who it is for
The brands this fits.
The common shape is a brand whose product tells somebody what to do next, and whose recommendation is only credible if it reflects what that person actually did.
Personalised nutrition brands
Fuelling and supplement guidance that adapts to training and recovery rather than to a form somebody filled in once.
Sports nutrition and supplement companies
Where the product recommendation is the commercial engine, so the reasoning behind it is worth owning.
Coaching and training platforms
Plans that adjust to how the week actually went, driven by the watch the athlete already owns.
Performance and recovery apps
Where the daily number is the reason somebody opens the app, and it carries your name rather than a vendor's.
What you can build
What teams build on it.
Everything below runs on data that arrives on its own, under your brand.
A fuelling plan that adapts
What somebody should eat around a session, adjusted for what the session actually was rather than what was scheduled three weeks ago.
A readiness number with your name on it
Your own score, built with your own logic on your customers' data, explainable by your team when somebody asks what moved it.
A product recommendation that earns trust
Suggestions tied to what the data shows, so the commercial side of the product reads as coaching rather than as an upsell.
The watches your athletes already train with.
Garmin, Strava, Polar and Suunto each have their own integration page, and each connected source arrives in the same schema, whichever one 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?
We sell nutrition, not software. Is this for us?
If your product gives personalised advice, then the data behind that advice is part of what you sell. This is the layer that collects it. The build itself is something your team does, or something we do with you, rather than a product you switch on.
Does it track food and calories?
No. Open Wearables brings in what the wearable measures: workouts, sleep, heart rate, recovery and body measurements. What somebody eats comes from your own logging or your nutrition database, and the value is in combining the two inside your database.
Which devices do athletes actually use?
Garmin, Strava, Polar and Suunto are where most endurance and training data lives, and each has its own integration page. Whatever somebody chose, the metric arrives in the same shape.
Can we build our own score?
Yes. Your team can build its own score with its own logic on the same data, and custom scores for your customers are built with our science team. Our health scores are part of Pro, designed and validated by that team.
Do we need our own provider credentials?
Yes, and they stay in your name, so the data relationship is between you and each provider. Approval is slow with some of them, so that work starts on day one.
Where does customer data live?
In the cloud account and region you choose at deployment, which is usually the shortest answer to a retail or enterprise partner asking the same question.
What if a customer switches from a watch to a ring?
Their history stays in your database and the new device lands in the same schema, so the timeline continues rather than restarting.
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.