Your users bring their own Apple Health. Straight from their iPhone to you.
Each of your users installs MetricBridge, pastes the endpoint and token you give them, and their phone starts POSTing signed JSON to your platform: 190 Apple Health and Watch metrics, workouts, sleep sessions, events. No SDK in your app, no vendor server holding the data, and no per-user fees.
Both buttons open an email to the founder, who replies personally. Please never send anyone's health data.
- Standard Webhooks v1 signatures
- JSON Schema 2020-12 and OpenAPI 3.1
- Reference receiver and conformance kit, zero dependencies
- Live on the App Store today
How it works
No MetricBridge server in the path. No account. Nothing stored by us.
Does it fit your stack?
What arrives
metrics.daily, metrics.intraday, workouts, sleep.sessions, timezone.changes, events. One endpoint, told apart by a header.
How it is signed
Standard Webhooks v1: webhook-id, webhook-timestamp, webhook-signature. Official libraries in JS, Python, Go, Ruby, Java, PHP, Rust and .NET, or 12 lines of your own.
Any backend
If it can accept an HTTPS POST and verify an HMAC, it works. Node, Python, Go, Rails, serverless functions, n8n. No iOS code on your side.
Any schedule you can live with
At least once, a few runs a day, duplicates expected, no ordering promise. Users can resend up to a year of history.
Verify a request in thirty seconds
Verification, the whole of it. The key is the user's token; the signed string is id.timestamp.body over the exact bytes received.
import crypto from 'node:crypto'
const expected = 'v1,' + crypto.createHmac('sha256', token).update(`${id}.${ts}.`).update(rawBody).digest('base64')
// token tok_secret, id msg_test, ts 1700000000, body {"data":{"metrics":[]}}
// → v1,0QJjrh8MGoEkAarUDlduSSytrxEA12L3Bte3lgJfNN8=Then prove the whole integration before a single user connects, from your laptop, with synthetic bodies:
curl -O https://www.healthexport.dev/examples/metricbridge-platform-kit.mjs
node metricbridge-platform-kit.mjs check --url https://api.yourplatform.com/metricbridge/u_test --token <token>
# 15 checks against the published contract; exit 1 if a MUST rule failsWhy device to platform, not cloud middleware
The established way to get Apple Health into a web platform is a cloud health-data API: you embed the vendor's SDK in your own iOS app, or your users install the vendor's companion app, and the vendor's cloud receives, normalises and stores everyone's data before forwarding it to you. Entry tiers published by Terra, Junction, ROOK, Sahha, Spike and Thryve sit between $299 and $499 a month, with caps of 500 to 1,000 users and per-user overage above that (vendor pricing pages, read 19 October 2026).
| Cloud health-data API | MetricBridge for platforms | |
|---|---|---|
| Who holds the data | The vendor's cloud, then you | Only you. Phone to your endpoint, nothing in between |
| What you ship | Their SDK inside your iOS app, or their companion app | Nothing. Your users install MetricBridge; you need no iOS app |
| Per-user cost to you | Caps and overage | Zero. Users buy the app once on the App Store |
| Contracts about health data | DPA with the vendor as processor | None with us. You are the controller; we never have it |
| Sources | Many wearables through one API | Apple Health only (everything the Watch and other apps write into it) |
| Freshness | Near real time via SDK | A few runs a day, when iOS allows and the phone is unlocked |
The last two rows are the honest trade. If you need Garmin and Oura through one API, or heartbeat-level real time, use a cloud API. If your users are on iPhone and your product should never have a middleman holding their health data, this is built for you.
Pricing
The contract, schemas, reference receiver and kit are free and open. Partner fees are flat. They buy listing, support and interoperability, and are never tied to data volume, data categories or how many of your users send data. We receive no payload and no per-record consideration, and that is written into the terms.
- Public contract, schemas, examples
- Reference receiver and conformance kit
- Listed on this page once your kit output passes
- Email support, best effort
- Receiver review against the contract
- Schema and field-mapping session
- Two 30-minute calls, email replies within one business day
- App Store offer codes for your pilot users
- Written success criteria and an end-of-pilot readout
- "Works with MetricBridge" badge and listing
- Versioned conformance report
- 90 days' notice and migration help on any contract change
- Named contact, replies within two business days
- Annual allotment of offer codes for onboarding campaigns
- Everything in Certified Partner
- Replies within one business day
- Quarterly integration and roadmap review
- Early notice of schema additions
- Co-marketing: launch post and a larger offer-code allotment
Prices in US dollars, excluding VAT where it applies. Offer codes are App Store offer codes for the MetricBridge unlock, bundled as co-marketing and never sold per code. A bespoke receiver built in your stack is available inside the pilot at a fixed quote. Each user still buys the app themselves, on the App Store, once.
What we will not do, so you know before you write
- Sign a business associate agreement (BAA), or act as a processor or sub-processor of health data
- Host an endpoint, relay, queue or "managed webhook" for you
- Price per user, per record or by data category
- Support clinical, diagnostic, monitoring or triage uses
- Support employer, insurer, school or family visibility into an individual's data
- Keep the contract additive and give partners notice before any breaking change
- Test only with synthetic data, and ask you to do the same when you write to us
- Answer from the person who wrote the code
- Say plainly that MetricBridge is a general wellness tool, not a medical device
- Publish the terms, the prices and the test suite, so nothing depends on a sales call
The full position, including the uses the licence terms exclude and why, is on the terms page.
Questions
Do we need to ship an SDK in our app?
No. Your users install MetricBridge on their iPhone and point it at the endpoint you give them. You receive signed JSON over HTTPS; there is nothing to embed, and you do not need an iOS app at all.
Does MetricBridge see our users' data?
No. The data goes from the user's phone straight to your endpoint. MetricBridge runs no server in that path, keeps no copy, and is not your processor. You are the controller of what your users send you.
Is pricing per user?
No, and it never will be. Partner fees are flat and buy listing, support and interoperability. They are never tied to data volume, data categories or how many users send data.
What does each user pay?
MetricBridge is a one-time unlock on the App Store (US price $24.99) that the user buys themselves. Pilots and partners get App Store offer codes to hand to their users as part of the package.
How do we identify which user a request belongs to?
By the endpoint path or the token you issued. The app carries no identity of its own; everything that identifies a person on your side is in what you gave them.
Can users send history?
Yes. "Resend past days" re-reads Apple Health for up to a year and sends the same bodies, marked with a replay header so you upsert rather than double count.
What about Android, Garmin or Oura?
Not today. MetricBridge reads Apple Health on iPhone, which includes anything the Apple Watch and other apps write into it. If your users are not on iPhone, a cloud health-data API is the right tool.
Is this allowed under Apple's HealthKit rules?
The user chooses to export their own data to a health or fitness service they use, and nobody in the chain may use it for advertising, sell it, or pass it to brokers. That is what Apple's guidelines require, and the terms bind you to the same conditions. We cannot give you legal advice; our own working notes are open to read.
Start with the guide, or start with a conversation
Not ready yet? Join the early-access list and pick "Building a platform" after you sign up.