$3,500 per platform, and what actually makes it hard
Pick the platforms your users actually wear. Each one carries a documented behaviour that costs real engineering time — silent permission denials, partial deduplication, membership-gated metrics — and each is shown next to its price rather than discovered in month two.
Estimated range
$7,000
2 platforms at the published $3,500 each. A straightforward read is the published price with no multiplier on top.
- Apple HealthKit
- $3,500
- Android Health Connect
- $3,500
This range excludes
- The app the data flows into — this is the integration only
- Developer-programme access fees or agreements a vendor may require
- Test hardware. Real-device QA needs the actual devices
- Aggregator subscription fees, which are quoted by volume
Platform behaviours noted here were verified against vendor documentation in September 2026. These APIs change; confirm current behaviour before committing a roadmap to it.
Where the time actually goes
Four things that cost more than the API call
Reading a step count is a morning’s work. Everything below is the rest of the project.
Deduplication is the real work
Several apps write steps to the same store. Which one is authoritative, and does the platform dedupe for you? On Health Connect the answer is only for Activity and Sleep — everything else silently sums.
You often cannot know what you were denied
HealthKit will not tell you a read permission was refused; the data just appears absent. Products that assume denial is detectable ship a broken empty state to a real subset of users.
Background delivery has its own rules
Entitlements, frequency caps and observers that get cut off after repeated failures. This is where 'it worked in testing' turns into 'the data stops arriving on day nine' in production.
Access is a scheduling risk
Several vendors gate API access behind a developer programme and an agreement, with timelines that vary. That is a roadmap dependency to start early, not a task to slot in the week before launch.
Methodology
Why per-platform pricing is the honest shape
The low end of the range is arithmetic: the published $3,500 per platform multiplied by how many you selected. The upper end applies a scope multiplier for two-way sync or near-real-time delivery with historical backfill, shown as a percentage because putting a hard dollar figure on “add webhooks” would be inventing one.
Integrations do not get cheaper in bulk, which is why there is no volume discount modelled here. Auth models, permission semantics, data shapes, background delivery and duplicate handling differ per platform, and almost nothing transfers between them except your own internal data model.
The per-platform notes in the tool were read at each vendor’s own documentation in September 2026 and recorded during a primary-source verification pass. These APIs move; the behaviours are stable enough to plan around but worth re-checking before a roadmap commits to one.
The unprofitable advice: integrate one platform first, based on what your users actually wear rather than on a matrix of everything competitors support. Most products need one well before they need six badly, and the second integration is far cheaper to justify once the first is producing data somebody looks at.
Integration questions
What teams ask before wiring in wearables
How much does a wearable integration cost?
Zee Palm's published price is $3,500 per platform — HealthKit, Health Connect, Garmin, Whoop, Fitbit or Oura — covering design, implementation, edge-case handling, QA on real devices and documentation. Two-way sync or near-real-time delivery with historical backfill adds scope on top, shown in this calculator as a percentage rather than an invented per-feature price.
Why is each platform priced separately instead of as one job?
Because they genuinely are separate projects. They differ in auth model, permission semantics, data shapes, background delivery, rate limits and how they handle duplicates. The work does not meaningfully compound: doing HealthKit does not make Whoop cheaper, because almost nothing transfers except your own internal data model.
What is the most common surprise in a wearable build?
Duplicate and missing data, not the API call. Health Connect's aggregate API deduplicates only Activity and Sleep — every other data type is summed across all writing apps with no deduplication, which is the mechanism behind double-counted steps and silently doubled nutrition or glucose totals. On the Apple side, HealthKit cannot report that a read permission was denied at all: denied reads simply look like no data, so your product has to be designed for permanent uncertainty about whether a metric exists.
Should I use an aggregator like Terra instead of direct integrations?
For two or three platforms, a direct build usually wins on total cost, because you pay once rather than per user forever. Past five or six, an aggregator often wins on time to market. The trade you are making is a one-off build cost for an ongoing per-user fee plus a dependency you do not control — and you inherit the aggregator's coverage claims rather than verifying each platform yourself. Device-coverage counts in aggregator marketing are claims, not audited figures.
Do I need the physical devices to build this?
Yes, and it is the line item most estimates omit. Real-device QA is the only way to catch background-delivery behaviour, permission edge cases and duplicate handling, none of which reproduce reliably in a simulator. Budget for the actual hardware for every platform you support.
Next steps
Go deeper on the data layer
Let’s create together
Tell us what your users wear and we'll tell you what it takes
Send the platforms and what data you need out of them. We'll come back with scope, sequence and a fixed price — and say so if one of them can't give you the metric you're planning on.