SYSTEM / CONNECTED HEALTH
Health context with explicit provenance
hello.food can combine Oura signals and consented Apple Health daily summaries with the user's dietary graph. Each provider has a different acquisition path, and the merged context retains its source, freshness, and privacy boundary.
Two providers, two data paths
- 01
Oura
The user completes an OAuth connection. Encrypted server-held tokens authorize provider reads, while live requests and a scheduled refresh keep readiness, sleep, activity, steps, active energy, and derived labels current.
- 02
Apple Health
HealthKit remains an iPhone capability. After separate health-sync consent, the iOS app uploads encrypted daily summaries for steps, active energy, sleep duration, and time in bed. The CLI never reads HealthKit directly.
- 03
Unified context
The service preserves provider labels and freshness when it merges available signals. The same bounded context can inform agent prompts, health tools, retrieval, and dietary guidance without pretending the sources are interchangeable.
The data contract stays narrow
| Source | Service-side handling | User control |
|---|---|---|
| Oura | Encrypted OAuth tokens; provider-labeled rolling context fetched live and by scheduled refresh. | Connect and disconnect the provider; disconnect removes the server-held integration tokens. |
| Apple Health | Encrypted daily aggregates only, owner-scoped and retained for 90 days. | Separate opt-in consent; revocation deletes the synced server copy in the same transaction. |
| Function Health | Planned. A provider type and coming-soon mobile tile exist, but there is no backend connector or data path. | No connection or health-data access is currently offered. |
What the Apple Health sync does not upload
- Raw HealthKit samples or sub-day timestamps.
- Workout records or location data.
- Health data for children or other household members.
- Any data before the owner explicitly grants health-sync consent.
Failed uploads are queued locally and retried on a later eligible sync. A server-side consent rejection clears local consent state and stops further uploads instead of treating transport as permission.
Health context can inform food guidance
Available Oura and Apple Health signals enter the same contextual layer as the dietary graph, meal history, and active household scope. Provider freshness remains visible, and a stale provider does not erase fresher context from another source. The result supports personalized food guidance; it is not a diagnosis or medical advice.
Native client preview
# Preview only — not in the released Python CLI
heyfood health status
heyfood health connect oura
heyfood health sync
heyfood health show --provider apple_health --days 30
heyfood health disconnect oura
heyfood ask "How should this week's sleep and activity change my meal plan?"Command grammar and rendered output remain subject to native-client qualification. Apple Health sync still originates on an authorized iPhone; a desktop CLI cannot access HealthKit.
Sensitive values stay out of diagnostics
- Health endpoints require an authenticated bearer session.
- Optional CLI scopes separate
health:readfromintegrations:manage. - Operational events carry provider labels, counts, and outcomes, not health values.
- Health-context responses are marked
no-store. - Decryption or lookup failure degrades the available context instead of exposing partial secrets.