Rook vs Spike: Which Health-Data API Fits Your Build?

Same category, opposite unknowns#

Neither of these is the vendor most teams shortlist first — that is usually Terra or Junction. So when Rook and Spike end up head-to-head, it is because a team has already decided the obvious choice does not fit, and what is left is the usage-priced, mobile-first one against the sales-led, everything-source one. Both halves of that sentence come with an unknown attached, and the unknowns are large enough to change the answer.

Rook is a unified wearable and health-data API and SDK built around usage-based, active-user pricing and strong out-of-the-box on-device support. Its SDKs integrate directly with Health Connect on Android and Apple Health on iOS using the OS permission model, and it covers activity, sleep, heart rate, body, and glucose or CGM across a stated 400-plus sources. It splits sources by extraction method — direct API integrations for centralized cloud providers, SDK-based extraction for on-device stores — which is why the mobile layer is more than marketing. Pricing is usage-based and tiered by active users, reported as named tiers (Core, Business, Enterprise) with a starter band up to roughly 750 active users, a growth band up to around 15,000, and custom above that.

Spike positions itself as a "Health 360-degree" API: a single integration layer that reaches past wearables into IoT and medical devices, EMRs, and lab tests, with an AI and analytics layer on top. It markets normalized, ingestion-ready data from over 500 wearables and platforms plus those non-wearable sources, and every organization gets a dedicated implementation engineer from the sandbox stage. Its pricing is tiered and sales-assisted with no durable itemized public figures — treat it as contact-sales.

So the axes are reach and how you learn the price. Rook's number is nearly visible and you can model it yourself; Spike's arrives through a person, and that person also helps you implement.

Rook vs Spike at a glance#

What we could not verify#

This section is deliberately not buried, because on this pair the gaps are large enough to change a decision.

For Rook: the official pricing page could not be verified — it returned a 403 to automated fetch — so the tier names and the active-user ceilings above are third-party reports, not confirmed rates. No per-user dollar figure was sourced at all. The 400-plus source count is vendor marketing. Confirm the tier caps against the live pricing page before you plan a growth curve around them, because "up to roughly 750 active users" is exactly the kind of number that quietly moves.

For Spike: specific tiers and figures were not retrievable at all. Its own materials cite inconsistent device counts (500-plus on one page, 200-plus on another), so do not anchor on a coverage number. The clinical framing, the generative-AI interpretation SDK, the food-photo nutrition extraction, and the MCP server are marketed capabilities — confirm each is production-ready before you design around it.

For both: no per-MAU or per-connection dollar rate is publicly confirmed for any aggregator in this category, and several vendor pricing pages return errors to automated fetching. A commonly quoted range of roughly 0.50 to 2 US dollars per connected user per month is a third-party category estimate, not either vendor's published rate. Do not budget against it. The health-data aggregator pricing breakdown explains how the models work when the numbers will not.

Where Rook wins#

You can model the bill before you talk to anyone. Active-user tiering is the most legible shape in this category: your cost tracks connected users, the bands are named, and you can sanity-check a launch budget against a growth curve without a sales cycle. Compare that with a contact-sales vendor, where the number that matters is negotiated and you cannot self-check the upper band at all. The caveat from the section above still stands — the ceilings are reported rather than confirmed — but a reported band beats no band.

The on-device half is first-class, not an afterthought. Rook's SDKs read Health Connect and Apple Health through the OS permission model, and the source catalogue is organized around that distinction. If a meaningful share of your users' data lives in the phone's health store rather than in a cloud account, that layer does work you would otherwise write yourself.

A bundled health score. Rook markets a proprietary score out of the box; with a plain aggregator you compute your own from normalized inputs.

The honest trade-off. Rook is a wearable-and-phone aggregator. Labs, EMR data and medical IoT are not its centre of gravity, and if your roadmap turns clinical you will be adding a second vendor. Several popular providers still need your own developer credentials, so budget onboarding time for those regardless of the tier you land on.

Where Spike wins#

Reach past the wrist. This is the decisive advantage and the reason to accept a sales conversation. A single API spanning consumer wearables plus IoT and medical devices, EMRs and lab tests is a different product from a wearable aggregator with a good SDK. For a clinical or medical-adjacent build, nothing in Rook's scope substitutes for it.

A human assigned to your implementation. Every organization gets a dedicated implementation engineer from the sandbox stage. That is a real, checkable differentiator — unusual in a category where onboarding is normally read-the-docs — and it partly offsets the opacity of the pricing.

AI-flavoured pieces already in the box. A generative-AI interpretation SDK, food-photo nutrition extraction, and an MCP server for connecting device data to an LLM sit alongside the aggregation layer, plus a low-code managed data-pipeline product. If those are on your roadmap, not assembling them yourself has value — verify each is production-ready first.

The honest trade-off. Spike is a newer, smaller company than the category leaders, and it publishes the least. You cannot estimate your cost before a call, its own device counts disagree with each other, and the AI features are marketing-stage until you confirm otherwise. For a small team with a wearables-only roadmap, that is a lot of uncertainty to buy.

How to choose#

• Mobile-first product leaning on Apple Health or Health Connect, with a budget you need to model today → Rook. The SDK layer and the named active-user bands are the two things it does that Spike does not.
• Clinical or medical-adjacent build needing labs, EMR data or medical IoT alongside wearables → Spike. Rook's scope does not reach there, and adding a second vendor later is worse than starting with the wider one.
• You want implementation help rather than documentation → Spike, for the dedicated engineer from sandbox onward.
• Latin America is your primary market → Rook is explicitly positioned there; verify the positioning still holds.
• Coverage of one specific provider decides it → neither count settles anything. Check that provider in each vendor's live integrations list, and check whether it is one of the ones needing your own credentials.
• You have not actually ruled out the category leaders → most teams should compare against Terra before settling here. Terra vs Rook and Terra vs Spike take those pairs directly, and Terra vs Vital (Junction) covers the wearables-plus-labs option this page does not.

Honest close#

Neither vendor saves you from the core aggregator trade: you are paying, on terms neither publishes cleanly, to remove per-provider integration work — and you still owe your own infrastructure, storage, token handling and health-data compliance on top. What separates them is narrow and real. Rook gives you a mobile-first architecture and a pricing shape you can model; Spike gives you reach into data Rook does not touch and a person to build with, at a price you will only learn by asking. Every count, tier and capability above is vendor-marketed or third-party reported as of 2026, and several could not be verified at all — re-check both vendors' live docs and get quotes before you commit. For the wider field, see the health-data aggregator APIs overview.