Apple Health API pricing in 2026: what the cloud APIs charge, and the flat-fee alternative

HealthKit costs nothing. The pipeline that gets the data off the phone costs $299 to $499 a month, plus a user cap, at every cloud vendor. Here is the arithmetic, and the version where no vendor sits in the middle.

Updated 20 October 2026 · 11 min read · The platform offer

AI-assisted, human reviewed. How we use AI

The quick answer

Apple's HealthKit API is free and always has been. What platforms actually pay for is a vendor that relays device data to a server, and the published entry tiers for that relay run $299 to $499 a month with caps of 500 to 1,000 users and per-user overage above the cap. MetricBridge takes the other route: the phone signs a webhook and POSTs it straight to your endpoint, so there is no relay, no processor in your data flow, and one flat annual fee that never scales with users or records.

What people mean by "the Apple Health API"

Two different things get called the Apple Health API, and the confusion is where most of the money goes.

• HealthKit, the on-device framework in iOS. Free. Read and write access to the metrics a user grants you. No server, no account, no invoice.
• A cloud health-data API, the thing you buy when you do not want to ship an iOS app of your own. It gives you a REST endpoint and a dashboard, and in exchange it holds the user's health data on its servers and bolts a companion app onto your onboarding.

HealthKit being free is why the second category looks expensive and also why it exists. Building a HealthKit client, an uploader, retry semantics, a signature scheme, versioned schemas and a receiver contract is weeks of work plus a review cycle, and most web-first coaching products do not have that team. The question is not whether the relay is worth money. It is whether you want the relay in the middle of your data flow at all.

Published entry tiers, read from the vendor pricing pages

Every figure below is the vendor's own published entry tier, read 19 October 2026. Caps are users or credits as the vendor states them; overage is per user above the cap unless noted.

Read the third column. At the 1,000-user mark a platform is committing somewhere between $3,588 and $5,988 a year for the entry tier alone, before any overage, and the cap arrives before most products find out whether those users stay. None of these numbers are secret or unfair. They are the price of a hosted relay with a support team behind it.

The cost of being in the wrong seat

Under GDPR, a vendor that receives health data and forwards it is a processor, and you are the controller who has to paper that relationship, audit it, and answer for it in your privacy policy. That is a recurring cost that never shows up on a pricing page: a data processing agreement, a subprocessor list you have to publish and monitor, a breach notification path that runs through someone else's incident channel, and a deletion request that has to be honoured in two systems instead of one.

There is a second, sharper reason to avoid per-user pricing on health data specifically. A fee that scales with the number of users sending health data, or with the categories they send, starts to look like consideration for the data itself. Washington's My Health My Data Act is written in exactly those terms, and Apple's broker and reseller rules sit in the same neighbourhood. Flat fees, with the number of users nowhere in the contract, keep the transaction clearly a licence for software. Per-user health-data billing does not.

The alternative: the phone talks to you directly

MetricBridge started as a consumer app that exports Apple Health to a user's own files. The platform version of that is the same pipe, pointed at your endpoint. The user pastes your URL and token into the app, picks a cadence, and from then on their iPhone builds the payload and signs it. Your receiver verifies an HMAC and stores it. MetricBridge's servers are not on the path, because there are no MetricBridge servers holding health data at all.

• Standard Webhooks v1 signature: base64(HMAC-SHA256(token, id + "." + timestamp + "." + body)), so the verification code you already write for other webhooks works here.
• Six typed deliveries: metrics.daily, metrics.intraday, workouts, sleep.sessions, timezone.changes, events, with published JSON Schema 2020-12 and an OpenAPI 3.1 description.
• 190 Apple Health metrics available on the device, chosen by the user, never selected or tuned by us for a partner.

What it costs instead

Four published prices, all flat, all on the platform page:

• Community, $0. The contract, the schemas, the conformance kit and a listing once your kit output passes. Best-effort email.
• Pilot, $2,500 fixed for 60 days, credited to year one. Receiver review, a mapping session, two 30 minute calls, 1 business day email, App Store offer codes for pilot users, written success criteria and a readout.
• Certified Partner, $1,800 a year. Badge and listing, a versioned conformance report, 90 days' notice and migration help on contract changes, a named contact at 2 business days, an offer-code allotment.
• Partner Plus, $3,600 a year. Everything above, 1 business day, quarterly review, early notice of schema additions, co-marketing and a larger allotment.

At 1,000 users, Partner Plus is $3,600 a year. The cheapest cloud entry tier on the table is $3,588 and the annual price bands of Terra, ROOK and Sahha annual land between $4,788 and $5,988. The gap is not the interesting part. The interesting part is that the MetricBridge number does not move when your user count does, and the incumbent number does, at exactly the moment a pilot turns into a business.

Sixty seconds of proof, before anyone trusts you

You should not take a contract on faith. The kit is a zero-dependency Node file that sends the same requests the iOS app sends, with the published synthetic example bodies, so you can prove the integration without a single real user:

node metricbridge-platform-kit.mjs check \
  --url https://api.example.com/metricbridge \
  --token "$WEBHOOK_TOKEN"

check runs 15 rules against your endpoint. The MUST rules are the ones that cost you data: a valid signature is accepted, a bad signature is rejected with a 401, a replayed timestamp is rejected, a duplicate webhook-id is treated as a no-op, and the connection test body is acknowledged without being stored. It exits 1 on any MUST failure, so it works in CI. send adds the edge cases one at a time, --bad-sig, --duplicate, --stale, --replay and --test, so you can watch your receiver do the right thing by hand.

That is the whole conformance conversation. A green run is the proof, and there is no version of it where I have to look at your data.

When a cloud API is still the right call

Be honest about the fit. Buy the relay if you need Android and Garmin and Oura in the same product this quarter, if you need a hosted dashboard for a support team that is not technical, or if you cannot ship an iOS client that holds a token. Those are real needs and the incumbents solve them.

MetricBridge fits when your users are on iPhone, when your stack already speaks webhooks, and when "no processor in the path" is a sentence you would like to put in your privacy policy and your sales deck. The audience is the long tail of web-first coaching and AI wellness products, not the big aggregators.

If that is you, the shortest path is: run check against your endpoint, then send one email. Details on the platform page and the integration guide at /docs/platforms/.

Questions people actually ask

Related reading

• → MetricBridge for platforms: the flat-fee offer
• → The integration guide: provisioning, verification, delivery
• → The webhook contract and schemas
• → Let your AI agent read your Apple Health data, privately
• → Export Apple Health data to JSON for AI (the pillar guide)