How to Add a Wearable API to an App That Already Has a Backend

Most wearable API integration guides assume a greenfield build: no existing backend, no schema, no mobile app already live. Pick a data model, wire up OAuth for each provider, ship it.

That's not the situation most teams are in. By the time a product needs a wearable API, it usually already has a backend serving real traffic, a schema other features depend on, and a mobile client already in the app stores. The integration has to slot into that live system. The top challenges when working with wearables in healthcare rarely mention this constraint directly, but it shapes almost every real integration we've been part of.

Heart Monitor is a useful example because it's a clean version of this exact situation. The app was live, running on a Hasura and GraphQL backend with a Flutter mobile client, serving 90,000 monthly active users who had no way to see their wearable data from Garmin, Apple Health, Samsung Health, and Google Health Connect in one place. Adding a wearable API took one engineer about a week, using Open Wearables as the data layer underneath. The full results are in the Heart Monitor case study; this article walks through what that week of integration into an existing backend involved, and why the schema mapping step is what determines whether that timeline holds.

Adding a Wearable API Starts With the Schema, Not the Providers

When a backend already exists, the hard part of adding a wearable API isn't authenticating with Garmin or parsing an Apple Health export. Open Wearables is an open-source, self-hosted platform that already handles the OAuth flows, provider-specific data shapes, and normalization into a single model, so that layer doesn't need to be rebuilt per integration.

The hard part is deciding how the new, normalized wearable data connects to a schema that already has its own conventions, its own naming, and its own assumptions baked into every resolver that touches it. A GraphQL API built over years accumulates decisions that made sense at the time: how a user record relates to a device record, what a "session" or "activity" means in this specific app, which fields are required, and which are optional. None of that changes because a new data source showed up. The new data has to conform to it, or the mapping has to bridge the gap explicitly.

For Heart Monitor, that meant taking Open Wearables' unified output and mapping it onto Hasura's existing GraphQL types and permission rules. Hasura generates its API surface directly from the underlying Postgres schema, so the mapping work was concentrated in a specific place: defining how wearable records related to existing user and device tables, and configuring which fields Hasura exposed through its auto-generated queries versus which needed a custom resolver. Our guide on multi-EHR integration covers a similar schema-mapping problem in a different data domain, where the same principle applies: the new source has to adapt to the existing model.

What Changes at the API Layer, and What Doesn't

The mistake teams make with existing-backend integrations is treating the new data source as a reason to touch more of the system than the mapping requires.

The mobile client, in this case a Flutter app, didn't need a rewrite. It needed new queries against the existing GraphQL endpoint, returning data shaped the way the rest of the app's data already was. The permission model didn't change either. Hasura's row-level permissions, already scoped to user identity for every other table in the schema, extended to the new wearable tables the same way, using the same access rules the rest of the app already enforced.

What did need explicit decisions: how a wearable-sourced sleep record related to any existing sleep-adjacent field the app already had; whether historical data on first connection needed a separate backfill path from the ongoing webhook-driven updates Open Wearables delivers; how the app's existing timezone handling applied to data now arriving from device-local timestamps rather than the app's own event stream; and how to deduplicate records when a provider resent data the app had already stored. These are the questions that take real engineering judgment, and they're specific to whatever the existing schema already assumes. A team going through this on their own backend should expect to spend most of the integration time here, not on the provider connections themselves.

Mobile client (Flutter): new queries against the existing GraphQL endpoint. No rewrite, no new screens.

Permission model: unchanged. Existing row-level rules extended to the new wearable tables.

Provider connections (OAuth, data shapes): handled by Open Wearables. Not rebuilt per provider.

Schema mapping (record relationships, backfill, timezones, deduplication): new work. This is what took the week.

Why Self-Hosting Mattered for This Specific Decision

Heart Monitor deployed Open Wearables with Docker Compose on their own infrastructure, the same infrastructure running the rest of the backend. That choice is relevant to the schema mapping question, not just to the data ownership argument that usually comes up around self-hosting. Heart Monitor's own engineering team handled that deployment; teams without the infrastructure bandwidth to take that on typically bring in infrastructure and security support to run the same self-hosted setup correctly the first time.

Running the wearables data layer on the same infrastructure as the existing Hasura instance meant the new system could sit next to the old one instead of behind a third party's API boundary. That's what health data integration looks like at the infrastructure level in practice: querying across both, joining wearable data with existing user records in a single request, is straightforward when both systems are on infrastructure the team already controls. It gets considerably harder when the wearable data lives behind a SaaS aggregator's endpoint, with its own latency profile and its own uptime dependency layered on top of every query that needs both data sets together. Our piece on why teams outgrow SaaS wearable aggregators covers that latency problem in more depth; we run into the existing-backend version of it on nearly every audit, because joining data across systems is standard practice, not something to design around later.

What a Week Actually Buys You Here

One engineer finished this in about a week, and it's a checkable claim, so it's useful to be precise about what that week included. It covers deploying Open Wearables, connecting the wearable providers Heart Monitor needed, mapping the unified data model onto the existing Hasura schema, and shipping the Flutter client changes to query it. A schema with more legacy structure, more edge cases in how existing tables model similar concepts, or stricter migration requirements around historical data will take longer.

What made a week realistic here is that the schema mapping decisions were contained. The existing data model was relatively clean, and the backend framework, Hasura, generates most of its API surface automatically once the underlying tables are defined. The mobile client also needed new queries rather than new screens, which kept the client-side work small. Teams evaluating their own timeline should check those same conditions on their own stack before assuming the same number applies.

Where a Wearable API Fits Into a Bigger Integration Project

Adding wearable data to an existing backend is one specific case inside the broader wearables integration problem, and it's usually the fastest path to wearable health data when the existing schema is reasonably clean. It's a different project from migrating off a SaaS aggregator, which involves moving already-live data rather than adding a new source, and different again from a backend that has accumulated enough legacy structure that the mapping work itself becomes the bulk of the project. Our overview of wearable data integration use cases covers how teams put the unified data to work once the mapping is done, and why mobile health apps struggle with wearable integrations goes into the fragmentation problem that makes a unified data model necessary in the first place.

For teams in that more complex position, the same underlying work still applies, though it takes longer. A short technical audit before committing to a timeline is usually the difference between an accurate estimate and a surprise three months in. Heart Monitor had the engineering capacity to run that mapping work themselves; teams that don't tend to bring in Momentum to scope and run the same integration as a services engagement, rather than pulling an engineer off the roadmap for a week or more.

Talk to Us About Adding Wearable Data to Your Existing Backend

If your app already has a backend, a schema, and a mobile client in production, and wearable data is the next thing to add, we're glad to walk through what the mapping work would look like on your specific stack. Get in touch to start that conversation.