Google Health + Stream Deck

Get the user's logged food and water intake, with aggregate calorie, macro and water totals. Example: startDate="2026-08-24" → entries: [{ time, foodDisplayName: "Greek yogurt", mealType: "BREAKFAST", calories: 180, totalFatG: 4.5, totalCarbohydrateG: 9 }], hydration: [{ time, milliliters: 500, liters: 0.5, flOz: 16.9 }], and totals. totals is one object covering the whole requested range, not per-day figures — call a single day at a time if daily breakdowns are wanted. Entries have no date-range limit, but totals are server-aggregated and cap the range at 90 days — set includeTotals=false to read entries over a longer span, which makes totals null. At most 1000 food entries and 1000 hydration entries come back per call (five pages of 200); truncated: true means there were more, so check it before treating the entry list as complete and narrow the range if it is set. Only food the user logged manually appears here; nothing is inferred from activity, so an empty result means nothing was logged, not that nothing was eaten. View docs

Get the user's total step count per day — the tool for any "how many steps" question. Returns one pre-aggregated total per day, not raw samples. Use Get Daily Activity Summary instead when distance, calories, active minutes, or floors are wanted alongside steps. The range is inclusive and capped at 90 days, because these totals are server-aggregated. Example: startDate="2026-08-17", endDate="2026-08-23" → days: [{ date, steps: 8432 }, ...] plus totalSteps, averageSteps, daysRequested and daysWithData. Set dataSourceFamily="google-wearables" to count only tracker-recorded steps, excluding manual entries. Days the tracker never reported are omitted from days entirely, so daysWithData can be lower than daysRequested and averageSteps is the mean over daysWithData. An empty days array means nothing synced, not zero steps — totalSteps and averageSteps are null in that case rather than 0. View docs

Get a full day of activity at once: steps, distance, calories, active minutes by intensity, active zone minutes by heart rate zone, and floors. The right tool when the user wants an overall picture of a day rather than one metric — use Get Daily Step Count for steps alone or Get Heart Rate for heart rate detail. The range is inclusive and capped at 14 days (calories and active minutes impose that limit on the aggregation). Example: startDate="2026-08-24" → days: [{ date, steps: 8432, distanceKm: 6.1, totalCalories: 2380, activeCalories: 620, activeMinutes: { light, moderate, vigorous, total }, activeZoneMinutes: { fatBurn, cardio, peak, total }, floors: 12 }]. Set dataSourceFamily="google-wearables" to exclude manually logged activity. A null metric means that one metric did not sync for that day and says nothing about the rest of the day — a day can carry real steps alongside a null distanceKm, so do not report the whole day as empty. An empty days array is the separate case where no activity data synced at all for the range. Never report either as zero. The API has no concept of daily goals, so no targets are returned. View docs

Read raw data points for any Google Health data type the dedicated tools do not cover — blood oxygen (oxygen-saturation), heart rate variability, respiratory rate, VO2 max, body temperature, exercise sessions, sedentary periods, altitude, swim lengths and more; see the dataType options for the full list. Prefer a dedicated tool where one exists, since those return compact pre-aggregated results while this returns raw records and can be large: Get Daily Step Count (steps), Get Daily Activity Summary (calories, distance, active minutes, floors), Get Heart Rate, Get Sleep Data, Get Body Measurements (weight, body fat), Get Nutrition and Hydration Logs (food, water). Example: dataType="oxygen-saturation", startDate="2026-08-24" → dataPoints with each reading's value and timestamp, newest first. Two pages of pageSize come back (default 50 → 100 records) and pageSize is capped at 500, so one call returns at most 1000 records; truncated: true means there were more — narrow the date range or raise pageSize up to that cap. food and food-measurement-unit are reference catalogues, not time series — the date range does not apply, the response sets dateFilterApplied: false, and you must not describe those results as belonging to a particular day. Not available here: total-calories, floors, and calories-in-heart-rate-zone are aggregate-only (use Get Daily Activity Summary); ECG and irregular-rhythm data need OAuth scopes this app does not request. View docs

Get the user's sleep sessions with per-stage totals, time asleep and awake, and a derived efficiency figure. A session is attributed to the date the user woke up, matching Fitbit — asking for 2026-08-24 returns the night of the 23rd into the 24th. Example: startDate="2026-08-24" → sessions: [{ startTime, endTime, type: "STAGES", isMainSleep: true, minutesAsleep: 431, minutesAwake: 48, efficiency: 0.9, stageTotals: { LIGHT: 240, DEEP: 71, REM: 120, AWAKE: 48 } }], plus mainSleep and totalMinutesAsleep. Three things to tell the user rather than invent: this API has no sleep score, so none is returned, and efficiency is computed here as time asleep over time in bed — not the figure Fitbit showed. Stage names depend on type, so read stageTotals rather than assuming a fixed set: STAGES sessions report LIGHT/DEEP/REM/AWAKE, older CLASSIC ones only ASLEEP/AWAKE/RESTLESS. Naps are separate sessions with isNap: true. At most 125 sessions per call; truncated: true means narrow the range. View docs

Get the connected user's Google Health identifiers: healthUserId and legacyUserId, the ID the same user had on the legacy Fitbit Web APIs. Use it to correlate records between a system that stored Fitbit IDs and one now on Google Health. Also the cheapest way to confirm the connection works, since it needs no synced data. Example: call with no parameters → returns { healthUserId: "NGL8Q2...", legacyUserId: "2E4RVC" }. legacyUserId is 1-63 characters of letters, numbers and hyphens — treat it as an opaque string and do not assume a fixed length or format. It is empty for users who never had a Fitbit account. View docs

Get the user's heart rate aggregated into time windows, plus their daily resting heart rate. Each window reports average, minimum, and maximum BPM; pick the window size with granularity. The range is inclusive and capped at 14 days, because the windows are server-aggregated. Example: startDate="2026-08-24", granularity="900s" → 96 fifteen-minute windows as { startTime, endTime, avgBpm, minBpm, maxBpm }, plus restingHeartRate: [{ date, bpm }] and an overall summary. Use granularity="86400s" for one figure per day. Resting heart rate comes back from this tool too — there is no separate resting-HR tool. For active zone minutes, which are heart-rate derived but reported as activity, use Get Daily Activity Summary. View docs

Get the user's weight logs with computed BMI, their body-fat percentage logs, and their current height. Raw logs, so there is no date cap; at most 1000 weigh-ins per call, with truncated set when there were more. Example: startDate="2026-08-01", endDate="2026-08-25" → weightLogs: [{ time, weightKg: 74.2, weightLb: 163.6, bmi: 22.9, notes }], bodyFatLogs: [{ time, percentage }], and height: { heightCm, heightIn, measuredAt }. weightLogs and bodyFatLogs are newest first. Two things to tell the user rather than guess: the API has no BMI field, so BMI is computed here as kg ÷ height in m² and is null when no height is on record. height is not measured over the requested range at all — it is the most recent height found in a ten-year lookback, capped at one page, so check measuredAt before calling it current: it can be years old, and when nothing turns up bmiComputable is false and every bmi is null. Body fat is measured separately from weight, so a weigh-in on a scale without body composition appears in weightLogs with no matching bodyFatLogs entry. Set includeBodyFat=false to skip the body-fat request entirely — bodyFatLogs then comes back empty because it was never asked for, which is not the same as the user having no body-fat data. View docs