Health data aggregator API pricing: how Terra, Junction, Rook, and Spike charge

What health-data aggregators cost

The short answer: unlike most first-party wearable APIs, a health-data aggregator is where you actually pay a recurring API bill. Aggregators like Terra, Junction (formerly Vital), Rook, and Spike almost universally price on active or connected users — variously called per-connected-user or per-monthly-active-user (per-MAU) — usually layered into tiered plans by user count with an enterprise "contact sales" top tier, and sometimes an extra credit or event dimension on top. The catch for budgeting is that almost none of these vendors publish self-serve dollar figures: most pricing pages sit behind a sales conversation, and several could not even be loaded during research. So treat the model below as the reliable part and every specific number as "not publicly listed — verify with the vendor."

What it actually costs

The honest way to read aggregator pricing is to separate the model (how they charge) from the numbers (what they charge), because the numbers are the part nobody publishes cleanly.

A few honest notes on that table. "Active user" or "MAU" is the near-universal unit — you generally pay for each end user whose wearable or app is connected and syncing in a given month, not per API call. Tiering by user count is the common wrapper: as your connected-user base grows you move up bands, and the largest band is almost always "contact sales." Terra is the one that most visibly adds a credit or event layer on top of the user count, so its bill has two dimensions rather than one. None of these is inherently "cheap" or "expensive" — the right frame is whether the per-user model fits how your product grows.

Critically: no per-MAU or per-connection dollar rate for any of these aggregators was verifiable during research, and several vendor pricing pages returned errors to automated fetching. Do not budget against a specific number you read secondhand — open the live pricing page or talk to sales before you commit.

The catch — what to budget for

The sticker (per-MAU or per-tier) is only part of the real cost. A few things bite:

• Your bill scales with your user base, by design. Per-MAU pricing is predictable to model but it grows directly with adoption. A pricing tier that looks fine at launch is a different number at 50,000 connected users — and that upper band is usually the "contact sales" one you can't self-check.
• Credits and events can be a second meter. Where a vendor (Terra, notably) layers a credit or event allowance on top of the user count, a data-heavy integration — high-frequency heart rate, sleep, workouts — can consume the allowance faster than user count alone suggests. Confirm how events are counted before you assume the base plan covers your volume.
• "Contact sales" means your real price is negotiated. For anything past the self-serve tiers, the number that matters comes out of a sales conversation, not a public page. Budget lead time for that, and expect annual commitments at the enterprise end.
• The aggregator fee doesn't replace your own costs. You still pay for your infrastructure, storage of high-volume wearable history, token and webhook handling, and health-data compliance (HIPAA/GDPR, encryption, BAAs). The aggregator removes integration labor, not your platform costs.

Why it costs money but can still save you money

First-party wearable APIs are mostly free to call, so why pay an aggregator at all? Because the aggregator is a build-vs-buy trade. Supporting many wearables directly means N separate first-party integrations — each with its own OAuth flow, its own approval process, its own schema, and its own ongoing maintenance as that provider changes. An aggregator collapses that into one integration and one normalized data stream, and charges you a recurring per-user fee for doing so.

The rough heuristic: few devices, engineering to spare, and willingness to do each approval favors going direct (low API fee, high integration and maintenance cost). Many devices, a desire for one integration, and a predictable per-MAU budget favors an aggregator (a real recurring fee, much lower maintenance). Most teams end up mixing. What you're buying is the removal of per-provider integration and upkeep work — whether that's worth the per-user price depends on how many providers you'd otherwise build and maintain yourself.

How it compares and cheaper paths

• For which aggregators exist and how they differ on coverage and features, see the health-data aggregator APIs overview.
• Weighing the two most-compared options head to head? See Terra vs Vital (Junction).
• To wire up a specific one, the Terra API integration guide walks through setup.
• If you only need one or two wearables, going direct may be the lower-fee path — first-party APIs are mostly free to call, and the wider fitness API cost breakdown covers the full build-vs-buy math.

Honest close

Aggregators are the part of the fitness-data landscape where recurring API spend genuinely accrues — but the exact numbers are the hardest to pin down, because most vendors keep them behind "contact sales" and their pricing pages frequently can't be read from the outside. The models above (per-MAU, tiered by user count, sometimes a credit layer, enterprise contact-sales) are stable enough to plan around. The prices are not. Re-open each vendor's live pricing page, or get a quote, before you budget against any figure — pricing here changes, and the public record is thin on purpose.