What breaks in year two of a wearable integration
Build-vs-buy posts model the first build. Two weeks per provider, a number for year one, maintenance as a flat percentage. None of them model the thing that actually costs you: the provider changing something you do not control.
- Four provider-side discontinuities landed inside roughly two years.
- One major programme has been closed to new applicants with no reopening date.
- Terms changes have arrived with around 30 days’ notice.
- Your maintenance estimate should be about provider churn, not about your own code.
| Provider | What happened | Notice |
|---|---|---|
| Strava | Nov 2024: third-party apps prohibited from displaying a user’s activity data to anyone but that user; API data barred from training AI models | Reported as around 30 days |
| Google Fit | Deprecated in favour of Health Connect. Published end-of-support dates have not been consistent between notices | Announced 2024 |
| Garmin | New API access applications paused. Developers report applying in Sept 2025, being rejected, reapplying in April 2026, and still waiting in August | No projected reopening date |
| Fitbit | Legacy Web API support ending, with the API scheduled to be turned off and migration to a new Google Health API | Announced in advance |
| Strava | 2026: flat monthly developer fee replacing tiered free access, some endpoints retired, public profiles behind auth | 90-day grace period |
Dates and details are from provider notices, developer forums and trade reporting. Check each against the provider’s current documentation before you plan against it — at least one of these has conflicting published dates.
“There is still no timeline for when processing will resume.”
“Product roadmaps, architecture and investment decisions have to move forward.”
“This uncertainty is preventing investors from moving forward with our app.”
Garmin developer forum, 2026. Worth reading as a risk model rather than as a complaint: access you cannot buy, on a timeline you cannot influence, is a dependency that belongs in your architecture review.
- Token refresh. Refresh rotates both tokens, so two workers refreshing one connection concurrently is a lost-update bug. It is a distributed-systems problem wearing an auth costume.
- Re-authorisation. Users revoke. The provider starts returning 401 and stops sending data. Somebody has to notice, and somebody has to ask the user again.
- Silent disconnects. The worst failure is the one where nothing errors and the data just stops.
- Enum and unit drift. A provider renames or adds a sleep stage in a minor release. Seconds versus minutes on sleep duration inflates a figure sixtyfold, quietly.
- Metric semantics. HRV is SDNN on some devices and RMSSD on others. The same number is not the same thing.
- 1Which providers are open to new applicants today, and how long is review taking?
- 2When a provider changes an endpoint, who does that work and on whose timeline?
- 3What does a user see when their connection breaks?
- 4What proportion of connections need re-authorisation in a year?
- 5What is the plan for the provider that closes its programme?
Buy when wearable data is an input to your product. Build when it is the product and you intend to staff it accordingly.
What does Humotron give us instead?
Ranked recommendations from your own catalogue and the reasoning with them, not raw streams or scores. The end-user consents to us directly, so provider churn and controllership both sit on our side.
Can we get the raw readings?
No, and that is the design rather than a gap. It is what keeps special category data out of your systems.
How do we test before committing?
Sandbox credentials run against synthetic data, so you can build the whole integration before anything real is involved.