Skip to main content

Integration Setup TODO

Manual follow-up steps for the Wellness OS integrations feature. All integrations currently show “Coming Soon” — this doc tracks what’s needed to go live.

Completed (Phase 1 — UI & Schema Foundation)

  • Add IntegrationTypeEnum (wearable, scale, cgm, app, ehr, email) to domain enums
  • Add IntegrationStatusEnum (available, connected, disconnected, coming_soon) to domain enums
  • Add legacy list exports (INTEGRATION_TYPES, INTEGRATION_STATUSES)
  • Create DataSourceDict TypedDict schema for state rendering
  • Re-export DataSourceDict from data/schemas/state/__init__.py
  • Add DEFAULT_INTEGRATION_SOURCES seed data (9 sources, all coming_soon)
  • Create integration_cards.py — reusable card, connect modal, suggest-a-device modal
  • Rewrite settings state chain (_base, _vars, _ui_handlers, _processes)
    • Replace partners / order_integrations with integration_sources
    • Add filtered_integration_sources and connected_sources_count computed vars
    • Add toggle_source_connection, set_integration_filter, suggest modal handlers
    • Load DEFAULT_INTEGRATION_SOURCES on settings load
  • Rebuild settings page with 3 new collapsible sections
    • Devices & Wearables (with sub-filter tabs: All, Wearables, CGM, Apps)
    • Health Records (coming soon)
    • Purchase Intelligence (coming soon)
  • Wire feature_coming_soon_dialog for unavailable sources
  • Write 12 unit tests (enums, seed data, TypedDict, AST state contracts)
  • Create docs/integrations/setup-todo.md

TODO: Database Layer (Phase 2 — required before any OAuth)

  • Create IntegrationConnection SQLModel in app/models/
    • Fields: user_id, source_id, access_token, refresh_token, token_expiry, last_sync, status
  • Add Alembic migration for integration_connection table
  • Create db_utils/integrations.py with CRUD operations
  • Update SettingsState._processes.py to load/save real connection status from DB
  • Add env vars to envs/template.base for each provider (see bottom of this doc)

TODO: Wearable & Device OAuth (Phase 3 — Priority: High)

Oura Ring

  • Register app at Oura Developer Portal
  • Obtain OAuth2 client ID + secret, add to envs/base
  • Implement OAuth2 PKCE flow (redirect callback at /api/integrations/oura/callback)
  • Map Oura API endpoints: sleep, readiness, activity → internal schema
  • Set is_available: True for Oura in DEFAULT_INTEGRATION_SOURCES

WHOOP

  • Apply for WHOOP Developer Platform access
  • Implement OAuth2 flow + token refresh
  • Map recovery, strain, sleep data → internal schema

Fitbit (Google)

  • Register at Google Cloud Console (Fitbit Web API)
  • Implement OAuth2 flow with Google Identity
  • Map activity, heart rate, sleep → internal schema

Garmin

  • Register at Garmin Developer Portal
  • Note: Garmin uses OAuth 1.0a (not 2.0)
  • Implement push-based data sync (Garmin Health API)

Apple Health

  • Requires native iOS app or HealthKit JS bridge
  • Consider using a third-party aggregator (e.g., Vital, Terra)
  • Apple Health cannot be accessed via web OAuth — needs mobile SDK

Google Health Connect

  • Requires Android app with Health Connect SDK
  • Consider using a third-party aggregator (e.g., Vital, Terra)
  • Not accessible via web OAuth — needs mobile SDK

TODO: CGM Integration (Phase 4 — Priority: High)

Dexcom CGM

  • Register at Dexcom Developer Portal
  • Implement OAuth2 flow for Dexcom API v3
  • Map glucose readings, calibrations, events → internal schema
  • Handle real-time data stream (5-min intervals)

TODO: EHR / Health Records (Phase 5 — Priority: Medium)

Epic MyChart (FHIR R4)

  • Register at Epic App Orchard
  • Implement SMART on FHIR OAuth2 flow
  • Map FHIR resources: Observation (labs), Condition, MedicationRequest
  • Handle patient consent / authorization scopes
  • Note: Epic sandbox available for testing before production access

TODO: Purchase Intelligence (Phase 6 — Priority: Medium)

Gmail Receipt Parsing

  • Evaluate Nylas Email API vs direct Gmail API
  • If Nylas: register app, implement OAuth, configure email read scopes
  • If Gmail API: register at Google Cloud Console, implement OAuth2
  • Build LLM-powered receipt parser (extract food/supplement items, quantities, prices)
  • Map parsed items → protocol/catalog entries
  • Handle consent: user explicitly authorizes email reading

DONE: Aggregator — reflex-junction (Vital/Junction)

Chose Junction (Vital) as the health data aggregator. Implemented as the reflex-junction pip package (libs/reflex-junction/).
  • Evaluate Vital API — selected, covers Oura, WHOOP, Fitbit, Garmin, Dexcom
  • Build reflex-junction Reflex custom component package (all 9 PRD phases complete)
  • Wire into Journals via JunctionService (PR #101, #104)
  • Wearable bonus scoring in diet pipeline
Per-provider OAuth is handled by Junction — no individual provider keys needed. See junction-wearables for full integration details.

Environment Variables

Active (in envs/base):
# Junction (Vital) — wearable health data aggregator
JUNCTION_API_KEY=sk_us_...
JUNCTION_ENVIRONMENT=sandbox

# Dexcom
DEXCOM_CLIENT_ID=
DEXCOM_CLIENT_SECRET=

# Epic FHIR
EPIC_CLIENT_ID=
EPIC_FHIR_BASE_URL=

# Nylas (if chosen for email)
NYLAS_CLIENT_ID=
NYLAS_CLIENT_SECRET=

# Vital (if chosen as aggregator)
VITAL_API_KEY=
VITAL_ENVIRONMENT=sandbox

Last updated: 2026-03-10