Alternatives and how it compares
When Open Health Sync fits, when a hosted wearables API or another open source aggregator fits better, and what each one gives you.
Open Health Sync is a self-hosted health data aggregator: one Go binary and Postgres that pull data from wearables and health apps, keep every raw payload, normalize it to one model with one set of units, and serve it as a REST API, FHIR R4, Open mHealth, CSV or Parquet files, and a read-only MCP server for AI agents, with signed webhooks when data changes. It is free and licensed AGPL-3.0.
This page answers the questions people ask before picking a tool. Facts about other projects were checked in October 2026; they change, so check their own pages too.
Common questions
How do I get my Apple Health data into a database?
Run Open Health Sync, then load the export the Health app writes on your iPhone
(Settings, Health, Export All Health Data) with ohs import apple-health. History included, it
lands in Postgres as samples, sleep, workouts and daily summaries you can query over the
REST API or with SQL. For continuous sync, an iOS app uploads new
HealthKit data to the Apple Health connector.
Is there a self-hosted alternative to a paid wearables API?
Yes. Hosted wearables APIs run the provider integrations for you and charge per connected user. Open Health Sync runs the same kind of integrations on your own server, at no cost beyond the hosting, and the data never leaves infrastructure you choose. The trade-off: you register your own developer application with each vendor, and you run the server.
How do I give Claude or another AI assistant access to my health data?
Open Health Sync includes an MCP server. Mint a read-only token for one person and add the server to Claude Desktop, Claude Code or any MCP client: the agent can read samples, sleep, workouts and daily summaries, and cannot write or delete anything. See Give your data to an AI agent.
How do I get wearable data as FHIR?
Open Health Sync serves FHIR R4 Observations (samples, blood pressure, sleep, workouts, daily summaries) with LOINC codes and UCUM units, checked with the official HL7 validator. See FHIR R4.
Which devices and apps does it support?
Thirteen sources are available: Apple Health, Health Connect (and through it Samsung Health and other Android apps), Withings, Oura, WHOOP, Strava, Polar, Fitbit, Suunto, Ultrahuman, intervals.icu, Dexcom and OMRON. Garmin and others are planned. The connectors page lists the status and integration path of each.
Compared with the other options
| Open Health Sync | Hosted wearables API | Other open source aggregators | Writing it yourself | |
|---|---|---|---|---|
| Where the data lives | Your server | The vendor's cloud, then yours | Your server | Your server |
| Cost | Free; you pay for hosting | Per connected user | Free; you pay for hosting | Your time |
| License | AGPL-3.0 | Proprietary | Varies (often MIT) | Yours |
| Standard outputs | FHIR R4, Open mHealth, CSV, Parquet, REST | Their own JSON | Usually their own JSON | What you build |
| AI agents | Read-only MCP server, stdio and HTTP | Varies | Some ship an MCP server | What you build |
| Raw payloads kept | Always | Varies | Optional or not | What you build |
| Runs on a Raspberry Pi | Yes, one binary | No | Usually several services | Depends |
| Vendor developer accounts | You register your own | Theirs | You register your own | You register your own |
| Dashboard and mobile app | Not yet: API first | Yes | Some ship both | What you build |
Pick Open Health Sync when
- You want the data on your own infrastructure, for privacy, cost or regulation.
- You need standard formats (FHIR R4, Open mHealth) rather than one more proprietary schema.
- You want an AI agent to read health data through MCP with a token that cannot write.
- You want every original payload kept, so you can re-process it when the mapping improves.
Pick something else when
- You need a provider that only a partner-approved company can reach today, such as Garmin, and you do not have that partnership. A hosted API that holds it may be the faster path.
- You want a ready-made dashboard or a consumer mobile app rather than an API.
- You cannot run a server and a database.
Next
- Quickstart: a running instance with data in a few minutes.
- How it works: the pipeline from raw payload to clean record.