Keep the original, not just the interpretation.
Open Wearables keeps both: the standard schema you query every day, and underneath it the payload exactly as the provider sent it.
Built on Open Wearables
What you get
What survives the trip into your database.
A normalised schema is someone's decision about what matters. Keeping the original next to it costs a bucket, and means you can still answer the question nobody asked yet.
The payload, before anything touched it.
What a provider sent is written down before normalisation runs, so the record is the provider's own structure rather than an interpretation of it. If a field never made it into the standard schema, it is still there.
- Pre-normalisation
- As sent
- Your bucket
You decide whether to keep them.
Retention is off until you switch it on, so a deployment that does not need the originals carries no extra storage. One setting turns it on, and the destination is a bucket you own.
- Off by default
- One setting
- No third party
Samples, not just daily totals.
Heart rate through the day rather than a single average, and workout detail where the provider sends it. The granularity the device recorded is the granularity you get to work with.
- Intraday samples
- Daily totals
- Both kept
A record that compounds.
A metric you invent next year can be computed against the history you already hold, rather than starting from the day you thought of it. That is the part teams notice late, usually when a question arrives that the old schema cannot answer.
- Full history
- Re-derive later
- No re-consent
The mapping is code you can read.
Normalisation is code in the repository you cloned, in files you can open. When somebody asks how a value in the standard schema was derived, the answer is a function rather than a support ticket.
- Open source
- MIT
- In your repo
Replay, not just archive.
Stored on-device payloads can be sent back through ingestion for a user, filtered by source or date range, with a dry run first.
- Replay tooling
- Filter by provider
- Dry run
How it works
Where the original goes.
Retention is a setting, and the destination is yours. Storage backend, size limits and what the stored objects look like are in the docs.
- 01
The provider sends what it sends.
A webhook fires, a scheduled pull returns, or a phone uploads through the SDK. Each one arrives in that provider's own shape, which is nothing like the next provider's.
Terminal
{"sleeps": [{ "summaryId": "x5b70ccc", "durationInSeconds": 29400, ... }] - 02
It is written down before anything reads it.
The payload goes to your bucket first, then processing starts. That order makes the stored copy the original, not a reconstruction, for webhooks, scheduled pulls and on-device uploads alike.
Terminal
s3://your-bucket/raw-payloads/garmin/webhook/2026-01-13/{user_id}/{file_id}.json - 03
Then it becomes the same shape as everything else.
Normalisation maps it into the standard schema, so sleep from one provider is queried like sleep from any other. The mapping is code in your repository, which is what you show someone asking how a number was derived.
Terminal
sleep_duration_seconds: 29400 · efficiency_percent: 87.0 · stages.deep_minutes: 95 - 04
You query the standard shape, and keep the original.
Day to day you work with the normalised model, because that is what joins against the rest of your product. The original is there for the question you have not been asked yet.
Raw payload storage in the docsTerminal
GET /api/v1/users/{user_id}/summaries/sleep
What's in your bucket
The originals, filed where you can find them.
The stored payloads sit in object storage in your own account, in a layout you can browse, query or show an auditor without asking us how it works.
- 01
By provider.
Each source gets its own folder, from a watch's cloud to the health store on a phone.
- 02
By how it arrived.
Webhooks, scheduled pulls and uploads from the phone are kept apart, so you can tell a push from a pull from an on-device sync.
- 03
By day and by user.
Under each, a folder per day, and within it a folder per user where the payload belongs to one person.
- 04
Labelled on the object.
Every file carries its source, provider, size and time, and the user and the batch it belongs to where there is one.
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, self-hosted | |
|---|---|---|---|
| [01] The original payload | Held on their side, if at all | Yours to store | Yours, in a bucket you name |
| [02] Fields outside their schema | Gone | Whatever you mapped | Still in the stored original |
| [03] Granularity | What their model exposes | What you built for | Samples where the provider sends them |
| [04] Explaining a number to a reviewer | Their documentation | Your code | Your code, from a repository you cloned |
| [05] A metric you invent later | Starts from today | Starts from your history | Starts from your history |
| [06] Who holds the archive | Them | You | You |
Who is it for
Different industries, one constraint: the data cannot sit in somebody else's cloud.
Digital health products
Coaching, scoring and analytics on the devices your users already wear, with a security review somewhere ahead.
Learn moreHealth data platforms
Wearable data next to the clinical record you hold, running in your own cloud under your own credentials.
Learn moreRemote patient monitoring
Readings from the patient's own device, in the record their clinician reads, in the country the data must stay.
Learn moreClinical and research builders
Endpoints that survive review, for teams heading for DiGA, CE or FDA and for research under ethics approval.
Learn moreCare providers
Remote monitoring for care programmes, clinics, senior care and virtual wards, with a patient app and a care view for your team.
Learn moreHospitals and telemedicine
Wearable data written into your EHR, with a source for every reading that clinicians and auditors can trust.
Learn more
What you own
What you actually own at the end.
The deployment, the data and the algorithms stay in your account, whoever runs it. What that means in practice.
Sovereignty
Health data does not sit in a third party's cloud. Where that is your regulator's rule, your board's policy or your own, the deployment satisfies it by architecture rather than by contract.
Residency
The data stays in the region you chose, and you can prove where it is by pointing at an account rather than at a trust page.
Control
You run it under your own credentials and decide who gets access. What you build on top of Open Wearables is yours.
Your own reasons
No regulator forcing it. You want the data in your own account anyway, and that is a sufficient reason.
Your raw data, from the devices your users wear.
Cloud providers push through webhooks and return through scheduled pulls. On-device sources upload through the SDK. All three paths write the payload down before it is normalised.
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.
FAQ
Do you have more questions?
Do you keep the raw provider data?
Only if you switch it on. Raw payload capture writes what a provider sent to a bucket you own, before any processing. It is off until you enable it, and adds nothing when off.
Why would we want the original if we already have the normalised version?
Because a standard schema is a decision about what matters, and decisions age. The usual trigger is a question nobody anticipated: a regulator asking how a number was derived, a clinician wanting the underlying samples, or a metric you want to compute across history you already hold.
Where is it stored?
In object storage you control, inside your own account. There is no copy on our side in either operating model, which is the difference between this and a hosted platform that keeps an archive for you.
How long is it kept?
For as long as your own storage policy says. Expiry is set on the bucket rather than by the application, so retention stays a decision you make and can evidence, not a default you inherited.
Can we do anything with the stored payloads, or is it just an archive?
Payloads that came from the phone can be sent back through ingestion for a user, filtered by provider, source or date range, with a dry run first. That is how a mapping fix is applied to on-device data you already have. Everything else stays a record you can read.
How granular is the data underneath?
Where a provider sends samples through the day, samples are what you get, rather than a daily average standing in for them. Workout detail is available where the provider exposes it. What any given provider actually sends is in the coverage matrix in the docs.
Is any of this different in the managed model?
No. When we deploy or maintain it for you, it still runs in your account, the bucket is still yours, and the repository is still the one you cloned. What changes is who does the work, under a DPA you sign.