Feature Idea: Health Data Import & Automated Sync (Google Takeout / Health Connect & Fitbit OAuth)

[t0msh]

Hi everyone,

First off, thanks for creating Yuvomi! The Health module is nice for tracking personal metrics, especially now I'm in my forties and health is more important to me than ever. To make logging easier, and improve the WAF (Wife Approval Factor), I'd like to propose adding options for importing and syncing health data from external sources, specifically within the Google/Fitbit ecosystem (because that's what I happen to use).

Context & Use Case

Since Google killed the Google Fit REST API in favor of Health Connect on Android and the Fitbit Web API for cloud data, users now fall into two main workflows:

1. Privacy-Conscious / Fully Offline Users: Want to export their health history from Google Takeout or Health Connect (as JSON or CSV) and upload it directly into Yuvomi without any cloud connections.
2. Automation Users: Want continuous background sync so vitals and activity data update automatically on their server dashboard.

Proposed Solution

I'd like to propose a two-tiered approach that respects user privacy while providing automation for the lazier among us who have already made peace with the fact that Google knows I'm a couch potato:

1. Manual File Import (Google Takeout / Health Connect Export)

• How it works: A file dropzone/upload button in the Health UI (public/pages/health.js) accepting Google Takeout or Health Connect JSON/CSV exports.
• Backend: A parser service (server/services/google-health-import.js) that converts raw activity and vital records into Yuvomi's health_vitals and health_activities tables.
• Benefits: 100% offline, zero cloud API dependencies, privacy-first.

2. Automated Background Sync (Fitbit Web API via OAuth 2.0)

• How it works: For users who prefer automatic sync, an optional integration via the Fitbit Web API (Google's official cloud REST API for Pixel Watch & Android fitness data).
• Backend: An OAuth 2.0 flow and scheduled background sync service in server/services/, following the exact same architecture Yuvomi currently uses for Google Calendar sync (server/services/google-calendar.js).
• Benefits: Continuous, hands-off background updating of steps, heart rate, weight, and workouts.

if there is interest in this, I would be more than happy to spend some time on it.

Looking forward to your feedback!

[ulsklyc]

Thanks - and the honest starting point is that the Health module today is entirely manual: /health/export/* exists for vitals, activities, labs and medication logs, and there is no import counterpart at all. So this is not "extend the import", it is "there is no import yet".

That makes the direction question worth settling before any provider is picked, and #639 asks for the same thing from the Apple side. Two possible shapes:

1. Yuvomi pulls. OAuth to Fitbit, tokens stored, a scheduler that fetches. Convenient for the household, but every provider is a separate integration with its own auth flow, its own rate limits and its own breaking changes - and this is a self-hosted app that a single person maintains. Google Takeout in particular is a manual export, not an API, so it cannot be automated in any real sense.
2. Something pushes into Yuvomi. The API token system already has a health scope, so a script or bridge can be granted exactly the health endpoints and nothing else. Every provider becomes somebody's small tool rather than a permanent commitment in this repo.

I lean towards the second, for the reason your own message hints at: the Google/Fitbit ecosystem is the one you are in, and the next person is in another. A general import path plus a documented token scope serves both; two hardcoded provider integrations serve two.

There is a real gap on that path though, and it is worth naming: the health endpoints have no change feed, so a bridge can write but cannot ask what changed since last time. Push-only works today; resumable sync would need something new.

Staying open. Would a documented import format plus a token scope be enough for what you want to build, or is the point specifically that Yuvomi does the fetching?

[ulsklyc]

@t0msh Coming back to this, because something changed that you should know before spending time on it.

The Fitbit Web API is being shut down this month. Google is retiring it in September 2026 and moving cloud access to the new Google Health API. Two details matter for what you proposed: existing OAuth tokens do not carry over, so every user has to consent again, and every scope on the new API is classified as Restricted - which means an application-level privacy and security review with Google before it can be used in production.

That last part is what decides it for a self-hosted app. A review per application does not survive contact with "everybody runs their own instance": either every household files its own review with Google, or one party holds a registration on behalf of all of them, which is precisely the shape Yuvomi does not have and does not want.

I am not raising this to close the door, and I would rather it read as information than as an I-told-you-so. But it is the clearest illustration available of the argument I gave you in August: had this gone into the core when you asked, it would be breaking this month, and the repair would be a migration every household had to perform for itself.

What has not changed:

• The file-import half of your proposal is untouched by any of this. Takeout and Health Connect exports are offline, they depend on nobody's API staying alive, and that is the half I still find convincing.
• The bridge route is better supported than it was. Third-party modules got widgets, their own permissions and translations in v2.63.0, and Sidecar extension platform for modules that need a backend (Akahu bank feeds, NZ) #746 is a working example with encrypted token storage and a scheduler.
• The gap I flagged is a ticket now, not a remark: Health API has no change feed: a bridge can read and write, but cannot ask what changed #1002. A bridge can push data in, but it cannot ask what changed since last time. That ticket also carries the batch and idempotency work raised in Proposal: optional Apple Health bridge using Yuvomi’s existing API #639.

The reasoning is written down in docs/SCOPE.md, section 2, so it does not have to be re-argued for the next provider.

[ulsklyc]

@t0msh Closing this, the same way as the Apple Health thread (#639). In August I wrote "staying open"; what was open then has a place of its own now.

docs/SCOPE.md, section 2 "Integrations with other people's services", entry "Health providers", puts Google Takeout, Health Connect and Fitbit outside the core and supported by the API: a bridge or a script reads the export or the provider and writes into Yuvomi with a health-scoped token. On 2 September I called the file-import half the one I still find convincing. That still holds for the files themselves - offline, dependent on nobody's API staying alive - but not for a parser in the core: an export format that changes without notice is the same upkeep as a provider API, and it sits better in a tool that can be released on its own.

The core's share lives in #1002, which is open and not started: the change feed, and noted there the ingest side - batch import, external_source / external_id and idempotent responses. My question from 24 August still stands - would a documented import format plus a token scope be enough for you? Answer it in #1002, or reply here and I will reopen.