Migrate from an aggregator to direct provider integrations

Move from an aggregator to direct provider integrations

You are taking one or more wearable providers off a health-data aggregator (Terra, Junction (formerly Vital), Rook, Spike) and integrating them directly with each provider's own API. The move is a real re-integration, not a config flip: you re-register your own developer apps, re-map from the aggregator's normalized schema back to each provider's raw schema, and every user must re-consent onto your own OAuth. The single biggest gotcha is that you take back all the maintenance the aggregator was absorbing — per-provider auth, token refresh, schema drift, webhook handling, and approval renewals — for every provider you bring in-house. Go provider-by-provider, run direct and aggregator paths in parallel, and keep the aggregator as your rollback path.

Why teams leave the aggregator

These are trade-offs, not universal wins. Weigh them per provider, not for your whole integration at once.

• Cost at scale. Per-connection or per-MAU aggregator fees can, for a high-volume provider, exceed what it costs to run that integration yourself. (Pricing is volatile — verify current terms with each vendor, as of 2026.)
• Data fidelity. A unified normalized schema drops or flattens fields that only exist on one provider. If you depend on a raw provider field that the aggregator does not pass through, direct access restores it. Confirm the provider still exposes that field before you migrate for it.
• Control and latency. Direct provider webhooks remove a hop, and you own retry and replay behavior instead of inheriting the aggregator's.
• Compliance and data residency. Some teams want the provider relationship and the data path in-house.

If you are still deciding whether direct is worth it versus staying consolidated, the aggregator concept and its trade-offs are covered in health-data aggregator APIs, and the reverse move is consolidate wearables with an aggregator.

What actually changes

Some providers are not self-serve even when you go direct. As of 2026, Garmin's Health API runs through a partner-program application that reviews your use case and data handling, and some premium metrics may carry license fees — verify current terms. WHOOP and Fitbit have their own app registration and review steps. Allow lead time in weeks, not days, and verify each provider's current developer terms before you commit a timeline. Fitbit's own direct setup is covered in integrate the Fitbit API.

The migration, step by step

1. Prioritize which providers to bring in-house. Usually the highest-volume providers (where cost bites) or the ones where you need raw fields (where fidelity bites) go first. Leave the long tail on the aggregator — you do not have to migrate everything.
2. Register direct developer apps and apply for approval early. Create your own developer app per provider and submit any required applications up front. Garmin, WHOOP, and Fitbit gate access behind review — verify current terms and allow weeks of lead time, as of 2026.
3. Re-map normalized to raw schemas. Map the aggregator's normalized model back to each provider's raw schema, field by field. This is fresh mapping work; confirm each provider still offers the specific fields you are migrating for.
4. Re-own ingestion, token storage, and refresh. Build per-provider webhook or polling ingestion, secure token storage, and refresh handling — the plumbing the aggregator used to run for you.
5. Re-consent users onto your own OAuth. For each migrated provider, users must re-authorize through your OAuth flow. Grants and refresh tokens held by the aggregator do not transfer, so plan a reconnect flow from the start.
6. Run direct and aggregator in parallel. Dual-read from both paths and compare values across a validation window before trusting the direct path.
7. Back-fill history directly from the provider. Pull historical data from each provider within its own cap. How far back you can go is set by the provider, not by you — verify current per-provider limits.
8. Cut over provider-by-provider. Migrate one provider at a time, keep the aggregator live for not-yet-migrated providers, and hold it as a rollback path until each direct integration is validated.

Gotchas and how to keep users connected

• Connections do not transfer. OAuth grants and refresh tokens are bound to the aggregator's app; your direct app needs a fresh user authorization. Design a clear in-app reconnect prompt and reconcile each provider user ID back to your own user. More on this in keep users connected during migration.
• You inherit approval renewals. Provider approvals can require periodic re-review or updated data-handling attestations. That upkeep is now yours — verify each provider's renewal terms.
• Raw fields may not survive the round trip. Confirm the provider still exposes the field you left the aggregator to get; do not assume a raw field exists just because the aggregator once flattened it.
• Back-fill is provider-capped. History depth is limited per provider, and large ranges may arrive asynchronously. Reconcile gaps against the aggregator path before you decommission it.
• Migrate in waves with monitoring. Track per-user connection state (aggregator-connected / reconnected / failed) so you can target reminders and never big-bang the cutover.

Honest close

This is a real re-integration with an ongoing cost: for every provider you bring in-house you take back the exact maintenance burden the aggregator removed — auth, token refresh, schema drift, webhook handling, and approval renewals. That can still be the right call for high-volume or high-fidelity providers, but treat it as a per-provider decision, not an all-or-nothing exit. Approval timelines, fees, rate limits, and back-fill caps all shift — verify current developer terms per provider before you plan the move.