Consolidate wearables: replace direct integrations with one aggregator

Replace direct integrations with an aggregator

You are maintaining several per-vendor integrations — Fitbit, Garmin, Oura, WHOOP, Strava — and each one is its own auth flow, its own schema, and its own webhook handler. Consolidating them behind one aggregator (Terra, Junction (formerly Vital), Rook, or Spike) collapses that into a single integration and a single normalized webhook stream. The move is real: you re-map fields to the aggregator's schema, some providers still need your own developer credentials, and every user has to re-authorize through the aggregator's connect flow. Run the aggregator in parallel with your existing integrations, back-fill within each provider's cap, and cut over provider-by-provider — this is a re-integration, not a flag flip.

For the concept itself, see what a health-data aggregator is and the aggregator category overview. This page is the move.

What actually changes

The value is concentration: aggregators advertise coverage of hundreds of sources normalized into one schema, typically spanning activity, sleep, heart rate, HRV, and body metrics (verify current coverage per vendor). You retire per-vendor schema drift and per-vendor webhook handling, which is the bulk of the ongoing maintenance.

The honest trade-offs:

• Recurring cost. Aggregators are paid platforms. At high volume this can exceed what your in-house maintenance costs, so model it against your provider count and user base (verify current pricing, as of 2026).
• Some providers still need your own credentials. "One integration" is marketing shorthand. Providers like Garmin, WHOOP, and Fitbit may still require you to register and get approved for your own developer app behind the aggregator. Junction documents that using your own OAuth app means the provider rate-limits you independently of the aggregator's default app (verify per provider).
• The normalized schema can hide fields. A unified schema drops or flattens fields that only exist on one provider. If you depend on a raw provider field, confirm the aggregator exposes a raw/passthrough payload before you commit (verify).
• You inherit a new dependency. The aggregator's reliability, latency, and support become yours to live with.

If your reasons point the other way — cost at scale, or needing raw provider fields the normalized schema drops — the reverse move is documented in aggregator to direct integration.

The migration, step by step

The ordered sequence is below. It follows the same parallel-run discipline as every migration: stand the new path up alongside the old, validate, then decommission.

1. Inventory your direct integrations. List every provider you run, the exact fields and endpoints you actually consume, and which webhooks fire. This map is what you validate the aggregator against.
2. Pick the aggregator and confirm coverage. Verify it covers all your live providers and the specific fields you depend on — including raw passthrough if you rely on provider-specific data. Setup for the target lives in the Terra integration guide.
3. Map your model to theirs. Map your internal/normalized model to the aggregator's normalized schema and list the gaps — fields the aggregator drops or renames.
4. Register any provider apps the aggregator still requires. Submit developer-app approvals for providers that gate access (Garmin, WHOOP, Fitbit) early — allow lead time, as approvals are not instant (verify current terms per provider).
5. Stand up the aggregator webhook in parallel. Run the aggregator's endpoint alongside your existing integrations. Verify its signature scheme, and pass your user ID as the aggregator's reference id (e.g. Terra's reference_id) so events map back to your users.
6. Re-consent users onto the connect flow. Users must re-authorize through the aggregator's connect/widget flow — old grants do not carry over. Migrate in waves and track per-user connection state so you can chase non-reconnected users.
7. Back-fill within each provider's cap. Pull historical data for migrated users, accepting that how far back you can go is set by each underlying provider, not the aggregator, and large ranges arrive asynchronously (verify current caps).
8. Compare, then cut over and decommission. Dual-read old vs new for a validation window, then cut over provider-by-provider and retire each direct integration once its replacement is proven.

Gotchas and how to keep users connected

• Connections do not transfer. OAuth grants and refresh tokens are bound to your old per-vendor apps. Every user re-authorizes on the new path, so design the re-consent UX from day one and keep old-path data flowing until each user reconnects. The cross-cutting playbook is keep users connected during migration.
• Back-fill is provider-capped, not aggregator-capped. Historical depth is set by each provider regardless of the aggregator. Document the gap for users rather than promising full history (verify current per-provider caps).
• Watch for silently dropped fields. If a provider-specific field matters to your product, confirm raw passthrough exists before you decommission the direct integration that still returns it.
• Don't hard-cut. Keep both paths live and a rollback available until each provider's replacement is validated per cohort.

How much effort is this really

Budget for a real re-integration: schema mapping, any provider approvals, a re-consent campaign, a back-fill pass, and a parallel-run validation window before you retire anything. The payoff is one integration and one webhook stream to maintain instead of many. Before you commit, verify current pricing, provider coverage, and back-fill caps directly with the aggregator, as of 2026 — those specifics move.