[Bug] Google Health API

[Uvenstedt]

HealthLog version

1.25.12

Deployment type

Self-hosted (Docker)

What happened?

The documentation states:

HealthLog reads Fitbit and Pixel data through the Google Health API. The OAuth app is therefore a Google Cloud OAuth client — not a Fitbit developer-console app.

However, clicking "Connect with Google Health" redirects to the legacy Fitbit OAuth endpoint instead of Google's OAuth. This can be verified in the browser URL bar:

fitbit.com/oauth2/authorize?response_type=code
&client_id=.apps.googleusercontent.com
&redirect_uri=https:///api/fitbit/callback
&scope=activity+cardio_fitness+heartrate+oxygen_saturation+profile+respiratory_rate+sleep+weight

Two issues are visible here:

Wrong authorization endpoint: fitbit.com/oauth2/authorize instead of accounts.google.com/o/oauth2/v2/auth
Wrong scopes: Legacy Fitbit scopes (activity, heartrate, sleep, etc.) instead of Google Health API scopes (googleapis.com/auth/googlehealth.activity_and_fitness.readonly, etc.)

This results in:

unauthorized_client - Invalid client_id

...which is expected — Fitbit's legacy endpoint does not accept Google Cloud OAuth Client IDs.

Expected behavior

Browser redirects to accounts.google.com/o/oauth2/v2/auth with Google Health API scopes
Actual: Browser redirects to fitbit.com/oauth2/authorize with legacy Fitbit scopes → unauthorized_client

Steps to reproduce

Steps to reproduce

Enable the Google Health API in Google Cloud Console
Create an OAuth 2.0 Web Client with redirect URI https:///api/fitbit/callback
Configure OAuth consent screen with Google Health scopes and add a test user
Paste Client ID and Secret into HealthLog → Settings → Integrations → Google Health
Click "Connect with Google Health"

Relevant logs / screenshots

Browser / OS (if applicable)

Chrome / Firefox

Pre-flight checks

• I confirmed this is not a duplicate of an existing issue.
• I redacted any secrets, tokens, or personal data from logs.

[MBombeck]

Hi @Uvenstedt, thank you so much for such a clear and well-researched report — the exact redirect URL, the scopes, and the unauthorized_client detail made this very easy to pin down. Genuinely appreciated. 🙏

You're completely right, and the good news is your setup was almost there: it's our documentation that was wrong, not the integration itself. Under the hood HealthLog connects through the classic Fitbit Web API, so it needs a Fitbit developer app from dev.fitbit.com — not a Google Cloud OAuth client. A Google Cloud client id (…apps.googleusercontent.com) simply isn't in Fitbit's registry, which is exactly why the Fitbit sign-in returns unauthorized_client — Invalid client_id.

You can connect today, without waiting for anything:

1. Register an app at https://dev.fitbit.com/apps/new
   • OAuth 2.0 Application Type: Personal if it's just your own account (this also gives you intraday data automatically); Server/Client if the instance connects other people.
   • Callback URL: https://<your-instance>/api/fitbit/callback
   • Scopes: activity cardio_fitness heartrate oxygen_saturation profile respiratory_rate sleep weight
2. Paste that Fitbit Client ID + Secret into Settings → Integrations → Fitbit, then click Connect with Fitbit.

I've opened #399 to fix the guide (and added a test so it can't quietly drift from the code again). Whenever you get a chance, could you try the dev.fitbit.com route above and let me know whether it connects on your end? I'd like to keep this open until you've been able to confirm it really works for you.

One honest heads-up so you can plan ahead: Google is retiring the classic Fitbit Web API in September 2026; the Google Health API replacement sits behind a verification + annual security-assessment barrier that doesn't fit self-hosting well, so the longer-term path there is something we're still working through.

Thanks again for the great report — it genuinely helped. 🙌

[Uvenstedt]

Hi @MBombeck thanks for the fast and thorough response! Unfortunately, the dev.fitbit.com route is no longer available for new users:

Important update:
The Fitbit Web APIs are moving to a new, scalable infrastructure. We will be deprecating the legacy Fitbit Web API in September 2026. Registration of new applications via this form is discontinued. To register a new application, please use the new process on the Google Health API developer site.

This message is shown at the top of https://dev.fitbit.com/apps/new — the form is disabled entirely, so I cannot register a new Fitbit app.

This means the classic Fitbit Web API integration is now a dead end for any new HealthLog user who doesn't already have a registered Fitbit app. Combined with the full deprecation in September, the migration to the Google Health API seems unavoidable at this point.

It seems like I then have to wait ^^

[MBombeck]

Two things shipped for this:

• v1.26.1 (merged to main) rewrites the setup guide to the classic Fitbit Web API flow — dev.fitbit.com app, correct scopes, HTTPS callback. That is what the "Connect" button actually speaks today, so the walkthrough and the code now match. A doc-parity test pins the guide to the client's real endpoints and scopes so they can't drift apart again.
• v1.27.0 (tagged just now) adds the integration you were setting up: a real Google Health connection (health.googleapis.com/v4) with a Google Cloud OAuth client, PKCE, and the googlehealth.*.readonly scopes — running alongside the classic Fitbit connection. Your Google Cloud client from the steps you described will work there; the redirect URI is /api/google-health/callback and the updated guide at docs/integrations/google-health.md walks through it, including the 7-day refresh-token expiry while the consent screen stays in Testing mode.

The image is publishing to GHCR now — v1.27.0 / :latest. Thanks for the precise report; the URL-bar breakdown made the diagnosis immediate.

[Uvenstedt]

Update: OAuth redirect is fixed and the connection works — connection test passes with ~1000ms latency. However, the sync itself has two issues.

After triggering "Sync all data", job.google_health_sync runs and successfully paginates through the API (24 pages of Steps, 24 pages of Distance, 23 pages of ActiveEnergy, plus Weight and BodyFat) but ultimately imports 0 measurements:

level: "warn"
task_name: "job.google_health_sync"
result: { users_synced: 1, total: 1, measurements_imported: 0 }

Additionally, four data types fail with HTTP 400:

GoogleHealthApiError: GoogleHealth fetchSpo2 error: 400
GoogleHealthApiError: GoogleHealth fetchFloors error: 400
GoogleHealthApiError: GoogleHealth fetchSleep error: 400
GoogleHealthApiError: GoogleHealth fetchExercise error: 400

So two separate problems:

1. Sleep, SpO₂, Exercise, and Floors return 400 — likely incorrect request format or endpoints for the Google Health API v4 schema.
2. Steps, Distance, ActiveEnergy, Weight, and BodyFat return 200 across dozens of pages but nothing is written to the DB — the API is clearly returning data (otherwise it wouldn't paginate through 24 pages), so the response parsing or data transformation probably doesn't match the Google Health API v4 response format.

Full external_calls array from the log is available if helpful. Happy to test any fixes on my end.

[MBombeck]

v1.27.4 is out and should fix both problems you found — thank you again, your log excerpt was exactly what cracked it.

The honest diagnosis: the integration was built against the documented v4 spec, and the live service answers differently in three systematic ways. Your report exposed all three:

1. Payload naming. Live responses key the data-point union in camelCase (bodyFat, sampleTime.physicalTime); the parsers were reading the snake_case form — which is only correct inside filter params. That's why steps/distance/energy/weight/body-fat paginated fine (24 pages of 200s) and still imported zero rows.
2. Large numbers arrive as strings ("12345", proto int64). The extractors accepted only JSON numbers.
3. Per-type read methods. Floors has no list at all; sleep filters only on interval.end_time; exercise sessions filter on an offset-less civil_start_time; SpO₂'s daily grain lives on daily-oxygen-saturation. Those four mismatches are your four HTTP 400s. Steps, distance, floors, and active energy now read as true daily totals via :dailyRollUp instead of walking minute-grain pages.

Also new in v1.27.4, for exactly this kind of debugging: Google's own error message now lands (shortened, credential-free) in the sync log, and the connection test accepts {"probe":"structure"} — POST /api/integrations/google-health/test — returning one sample request per data type reduced to field names and value kinds, never actual readings.

Could you update to v1.27.4 and run "Sync all data" again? Everything above is verified against the official reference, but you have the only live account in this conversation. If any type still misbehaves, the structure probe output plus the new error lines in the sync log would pin the rest immediately.

[MBombeck]

Update: v1.27.12 is out and fixes the last red path — the daily-totals read (steps / distance / floors / active energy).

Two things were wrong: the roll-up request bounded its range with an exclusive end date, so a maximal window spanned 91 civil days against the API's 90-day cap (hence the blanket 400 INVALID_ARGUMENT), and that one failure suppressed the neighbouring cumulative types. The request now mirrors the documented example exactly (end = last covered day, 23:59:59), each cumulative type fetches independently, and Google's field-violation details now surface in the error text, so any residual rejection names the offending field outright.

The fix is confirmed against the live API on a connected account: all cumulative types return 200 and daily step totals import (the googleHealth.rollup.shape log annotation reports days90, so the standard window holds).

The connection test's structure probe also covers the roll-up read now — after pulling :latest, "Verbindung testen" → structure probe shows the roll-up response skeleton alongside the list types. If you get a chance to re-test on your instance, one manual sync should bring everything in. One general note for fresh devices: sleep-derived metrics (sleep stages, HRV, resting HR, SpO₂, respiratory rate) only exist after the first full night.

[MBombeck]

One more, and this is the big one for you: v1.27.15 completed a full 40-type coverage audit of the Google Health API and fixed three more silent zero-import bugs — the kind that return HTTP 200 but write no rows, so they're invisible without exactly the sort of log you sent.

• HRV, resting heart rate, SpO₂, respiratory rate, VO₂max — all five daily-summary types filtered with a date-field style the live service never matches. Google's own docs contradict each other here (the data-types index says snake_case daily_heart_rate_variability.date; the dataPoints.list reference's only worked example uses camelCase dailyHeartRateVariability.date). We sent snake → 200 with zero rows while the data sat visibly in the app. The sync now sends the worked-example form and self-heals to the alternative on a first-page 400, and the connection test reports which one your instance's service accepted (requestShape / the googleHealth.dateFilter.style log annotation).
• Respiratory rate additionally read a field that doesn't exist, and height parsed metres where the API sends millimetres — both silent since launch.
• Newly imported: blood glucose, core body temperature, and the nightly wrist temperature Fitbit bands record during sleep. Plus ~35 more exercise types (trail runs, pool swims, rowing machines) that used to land as "other".

So after pulling :latest (now v1.27.15+): a manual sync should bring HRV and resting HR through, and the log line tells you which filter grammar your service accepted. If either grammar still returns empty for a type, that's Google-side materialisation for the account, not us — the annotation makes it distinguishable. The full audited type-by-type matrix lives in the repo at src/lib/google-health/mapping.md if you want to see exactly what's imported vs. deliberately skipped.

Thanks again — your logs drove three separate fixes now.