Do I have to run the official Observatory hub?

No. HealthSave syncs to any server that speaks the documented contract — the official hub, a community implementation like health-data-to-mqtt, or something you write yourself in an afternoon.

Backends that speak HealthSave: the hub, the community, and yours

Q: Is the HealthSave server open source?

The protocol and SDK layers of HealthSave Observatory are open source, and the self-hosted server core is source-available under the Elastic License 2.0. The API contract itself is openly documented, and any server that implements it works with the app.

Q: Does HealthSave send my data anywhere besides my server?

No. There is no HealthSave cloud in the path. The app reads Apple Health on-device and sends data only to the destination you configure, authenticated with your own optional API key.

Q: How do I get my backend listed here?

Build something that speaks the contract, put it on a public repo, and email support@healthsave.app. If it works against the documented endpoints, we'll link it.

Updated July 12, 2026

HealthSave syncs your Apple Health data to a server you own, over an openly documented API contract — which means the backend doesn't have to be ours. There's an official self-hosted hub with dashboards and a database, there are community reimplementations that route the same data into entirely different stacks, and there's nothing stopping you from writing your own in an afternoon. This page is the map.

The contract in one paragraph

The app POSTs batched samples to versioned endpoints — quantity samples, sleep, workouts, activity summaries, blood-pressure correlations, category events, ECG — with an optional x-api-key header on every request (including the liveness probe), plus a status contract so the app can display sync state. Full endpoint-by-endpoint documentation lives at healthsave.app/api.html, and every metric's exact identifier is in the metrics reference. Any server that implements the contract works — the app doesn't care what's behind the endpoint.

The official hub: HealthSave Observatory

github.com/umutkeltek/healthsave-observatory — the reference implementation we build and run ourselves. Python/FastAPI over TimescaleDB, deployed with Docker Compose, with web dashboards and a REST API over your synced history. The protocol and SDK layers are open source; the server core is source-available under the Elastic License 2.0. If you want the full picture — long-term history, Grafana, Home Assistant, your own API — this is the batteries-included path.

Community backends

These are servers other people built against the contract, for their own stacks, and published:

health-data-to-mqtt — TypeScript, straight to MQTT

github.com/bietiekay/health-data-to-mqtt — a small-footprint Node.js/TypeScript server that accepts the same sync batches and republishes them to MQTT topics instead of storing them in TimescaleDB. Built by a user who needed alerting in MQTT-connected systems: heart rate, blood oxygen, sleep, and workouts land directly on your broker, where Home Assistant's MQTT integration or Node-RED picks them up. It's also simply a clean, readable second implementation of the contract — useful reading if you're writing your own.

Building your own: advice from real deployments

The contract is small enough to implement in an afternoon, but production traffic has real shapes. These lessons come from actual self-hosted deployments and the support threads they generated:

Always answer with a real HTTP error — never kill the socket. One self-hoster's proxy enforced a body-size cap by destroying the connection on oversized POSTs. A dropped connection looks like a transient network failure, which is retryable — so the app retried the same oversized batch, which failed the same way, indefinitely. Return a clean 413 Payload Too Large and the client can react sensibly.
Size your request-body limit for workout batches. Workouts carry GPS route arrays and heart-rate sample arrays; multi-year backfills produce batches that are legitimately large but bounded. 5 MB is too small; that same deployment settled on 64 MB and never hit the cap again.
Log cap breaches distinctly. If your server rejects a batch, make it show up in your logs as a rejection — not as something indistinguishable from a network blip. Future-you will diagnose in minutes instead of days.
Implement the status contract. It's how the app tells the user sync is healthy. Skipping it works, but you lose the in-app visibility that makes self-hosting feel trustworthy.
Expect conservative client behavior. If your server rejects a batch, HealthSave stops that metric type rather than skipping past it — ordering is protected by design. The user-side recovery is Reset Sync Progress + Backfill.

Get listed here

Built a backend that speaks the contract — a different database, a different language, a different destination entirely? Put it on a public repo and email support@healthsave.app. If it works against the documented endpoints, we'll link it on this page.

Frequently asked questions

Is the HealthSave server open source?

The Observatory's protocol and SDK layers are open source; the server core is source-available under the Elastic License 2.0. The API contract itself is openly documented — and that's the part that matters for building your own.

Do I have to run the official hub?

No. Any server that speaks the contract works — official, community, or yours.

Does HealthSave send my data anywhere besides my server?

No. There's no HealthSave cloud in the path — the app reads Apple Health on-device and sends only to the destination you configure.

How do I get my backend listed?

Public repo + email us. If it implements the contract, it belongs here.

HealthSave: Export Health Data, on iPhoneGet on the App Store