What we Learned Building Wearable Integrations, Packaged Into Signal

After dozens of wearable integrations, we started noticing the same pattern. Provider documentation tells you how to call an endpoint. It doesn't tell you what happens when data arrives six hours late, when the same HRV metric means something different depending on who made the device, or when Apple Health seems like the obvious choice until you look closely at what your product actually loses by going that route.

These aren't problems you see coming. They show up three months after launch, when real users are using your product in ways that don't resemble your test environment. By then, they're expensive to fix.

When Documentation Ends and Production Begins

Provider documentation tells you how an API works. It doesn't tell you how data behaves once it's flowing through a real system with real users.

Garmin might deliver yesterday's workout data the next morning. Polar might send a webhook that never arrives. A user disconnects their device, reconnects it, and you get duplicates. These behaviors aren't edge cases, they're the normal operating conditions of production wearable data. Building around them requires a separate engineering layer that no quickstart guide covers.

The tricky part is that each provider has its own delivery model. Some push data through webhooks, some require polling, some batch overnight. Some are reliable enough that you can build directly against them; others need buffering and retry logic before the data is trustworthy enough to show a user. If you're integrating more than one provider, you're not just building an integration, you're building a pipeline that needs to handle all of their different failure modes at once.

This is the kind of work that takes weeks to get right and tends to get underestimated at the planning stage, because it's invisible until it breaks.

The Aggregator Trade-off: When Apple Health Is and Isn't the Right Call

Apple Health and Google Health Connect are genuinely useful. A single integration that covers hundreds of devices is an appealing architecture, especially early when you're trying to move fast. But both aggregators come with constraints that documentation doesn't describe clearly.

Apple Health requires a native iOS app. There's no backend API, the data lives on the user's device, and your app needs to be present to read it. That's fine if you're building a native mobile experience, but it rules out web-first products and anything that needs server-side access to raw data without the user actively opening the app.

Google Health Connect has its own set of trade-offs: Android-only, varying levels of data availability depending on which apps a user has installed, and a permissions model that can be unintuitive to users who haven't encountered it before.

None of this makes aggregators the wrong choice. For many products, they're exactly right. The issue is that the choice between aggregating and going direct to providers is an architectural decision made early, and it shapes your roadmap for years. Getting it right depends on understanding your specific use case: who your users are, what devices they're likely to have, what data you actually need, and how you need to access it.

HRV Is Not One Metric

If you're building any kind of wellness or recovery product, HRV is probably on your roadmap. It's also one of the clearest examples of a problem that doesn't show up until users start comparing numbers.

HRV isn't a universal metric. The label is consistent across providers; the calculation isn't. Garmin uses a different method than Polar. Polar uses a different method than Whoop. The differences aren't trivial, two devices worn on the same night by the same person can return meaningfully different numbers, and both are technically correct given their respective methodologies.

This doesn't break anything in your unit tests. It breaks trust when a user switches devices and asks why their score dropped, or when they wear two trackers simultaneously and see different values. At that point, the problem isn't their expectation, it's that your product treated different measurements as equivalent.

The fix is normalization: knowing which calculation each provider uses and either presenting the differences transparently or standardizing across providers before surfacing the data to users. It's solvable, but it requires understanding the underlying methodology, not just the API field names.

What Signal Does With These Problems

These three problems, pipeline reliability, provider selection, and metric normalization, aren't unusual. They're the standard set of challenges that every team encounters when they move from a working prototype to a production system with real users. The question isn't whether you'll face them; it's when, and how much of your roadmap they'll consume when you do.

At Momentum, we've worked through these problems enough times that we've built them into how we approach wearable health projects from the start. That's what shaped Signal, our delivery framework for wearable health intelligence.

Signal works in three phases, and the first two address everything described above directly.

The Blueprint phase is where architecture decisions get made before they become expensive mistakes. We map your use case, your target users, and the devices they're likely to carry, and from that we determine whether direct provider integrations or aggregators like Apple Health make sense for your product. This isn't a generic recommendation; it's specific to what you're building. The tradeoffs described above, around background sync, server-side access, and user experience, get resolved before a line of code is written.

The Foundation phase is where the pipeline gets built. This is the layer that handles webhook delivery from Garmin, retry logic for Polar, deduplication when a user reconnects a device, and late-arriving data from devices that were offline for days. It also handles normalization across providers, which means HRV from Whoop and HRV from Oura arrive in your product as comparable, contextualized signals rather than two unrelated numbers with the same label. By the time Foundation is complete, the data underneath your product is clean, consistent, and trustworthy, built on Open Wearables, our open-source, self-hosted integration layer with zero per-user fees.

The Intelligence phase is where that clean foundation becomes useful to your users: fatigue modeling, recovery readiness, trend analysis, personalized AI coaching. That work is only possible because the data underneath it is reliable. Teams that skip straight to intelligence without getting the foundation right are the ones who end up rebuilding six months later.

We bring the integrations, the data layer, and the intelligence. Your team ships the experience.

You can read more about how Signal works at themomentum.ai/signal.