Integrations

Import-only: how it works

Ojava health-data paths are read-only. When you import a supported export today, or use a connection after its activation gate is verified, Ojava brings selected data in for organization and insight. We do not send anything back to those apps, and we do not sell your data to them or anyone else. Your health data stays private to your Ojava account.

Connected grocery handoff

The Meal Plan grocery card can prepare an optional Kroger cart handoff from your reviewed list. You connect your own Kroger account, choose a store, search the official store catalog, and pick the exact product for each grocery item. Ojava then shows a final preview. Nothing reaches Kroger until you check the purpose-specific consent box and confirm that one preview. The handoff adds UPCs and quantities to the Kroger cart only. It does not check out, charge a payment method, choose substitutions, schedule delivery, or place an order.

Kroger support stays visibly unavailable until Kroger approves the application and the server-only credentials, redirect URL, encryption key, rate limiter, database migration, and activation switch are verified. If activation is paused later, an existing connection remains visible so you can export its non-secret history or disconnect it, while new store search, preview, and cart actions stay disabled. The export action is enabled only while Ojava confirms that its private grocery storage is available. Once storage is active, grocery-history export remains available after disconnect. Every action is bound to the active patient, so profiles under the same account keep separate connection and handoff history. If Kroger times out, rate limits the request, returns a server error, or loses the connection after a cart request, Ojava does not retry automatically. An interrupted request remains blocked from reuse, and Ojava asks you to inspect the Kroger cart first so duplicate items are not created. Preparing another preview stays paused until you acknowledge that you checked the cart.

Chicory remains a provider-managed recipe activation path. Ojava will expose its official link only after Chicory approval supplies a usable publisher contract and approved HTTPS activation URL. Private meal-plan groceries are not sent to a Chicory widget, and Ojava does not invent a private Chicory API while approval is pending.

Kroger OAuth tokens are encrypted with a server-only key and never returned to the browser. Token refresh is serialized so two requests cannot race a rotating refresh token. An expired or uncertain refresh grant asks you to reconnect instead of retrying an old credential. Disconnecting deletes Ojava's local encrypted token record. Kroger's public API documentation does not currently confirm a revocation endpoint, so also remove Ojava from Kroger's authorized-app controls if Kroger shows that option. Account deletion removes connection, OAuth, and handoff records by database cascade. The grocery card can export complete, paginated connection and reviewed-handoff history as JSON; access tokens, refresh tokens, confirmation nonces, and confirmation digests are always excluded.

Three ways to import

Choose the method that fits what you want to connect:

File import (live today)

Export a file from any app or device (lab PDF, wearable CSV, C-CDA health record XML, Bulk FHIR NDJSON, HL7 v2 ORU lab message, medication list, etc.) and drop it into Ojava's Ingestion page. Ojava auto-detects the type, extracts the data, and queues it for your review before it joins your record. Nutrition diary CSVs that belong in the Food Log, such as MyFitnessPal meal exports, are reviewed inside the nutrition tracker instead of the medical-record review queue. This works for any app that has an export function, so it is the broadest method today. See Records & search for details on supported formats.

Apple Health and Google Health Connect

The native app code now has a foreground sync action for Apple Health on iOS and Google Health Connect on Android. In a signed native build, after you grant device permission, Ojava can read supported health-hub categories such as steps, heart rate, sleep, HRV, workout sessions, body metrics, oxygen, blood pressure, glucose, total energy burned, basal body temperature, and related readings. The current native adapter does not expose dietary macro or water-intake samples, so those remain on reviewed file imports, nutrition-app imports, and manual tracker rows until a truthful adapter or provider path exists. Public activation still depends on the native app release, iOS HealthKit capability, Android Health Connect permission review, and your selected consent scope. Until those rails are verified, file import is the live path on web.

For WHOOP on Android, Ojava treats Health Connect as a health-hub path, not a direct device connection. WHOOP documents an Android Health Connect integration, and Google Health describes WHOOP data as syncing through the WHOOP app and Health Connect rather than directly from the tracker. Ojava can only treat those readings as source evidence after the signed Android app is approved, you grant Health Connect permissions, and WHOOP rows are actually present through Health Connect or an imported WHOOP file. It does not store Google Health credentials, write back to WHOOP or Google Health, control the device, monitor in real time, or send alerts.

Google Health cloud connection

Ojava now has a separate read-only connector for Google's official Health API. Once its production activation is complete, an authenticated user can grant activity, health-measurement, and sleep access, then bring supported Google Health rows into the same private wearable record used by native sync and reviewed imports. The connector supports reconnect, manual refresh, scheduled refresh, disconnect, account deletion, and token-free export metadata. It never writes data back to Google Health.

The first connection reads the available Google Health history in resumable pages. Ojava stores progress separately for each data type covered by the access you granted, so a large history continues in the background without starting over. Connection status shows which activity, measurement, or sleep rails are shared, which are unavailable, and how many authorized data types have finished their initial history. Reconnecting can add access, which restarts full-history import for the expanded set. Later refreshes use bounded overlapping windows and the same deduplicated wearable record.

If Google rejects a saved continuation token, Ojava retries that same history window once from its beginning without advancing the saved coverage point. A second rejection pauses the connection and shows that reconnect is required. Reconnecting clears the stalled cursor and starts a fresh, deduplicated full-history import instead of repeating an endless restart loop. The token-free export records this recovery status but never includes the rejected token or any OAuth credential.

In the signed iOS and Android apps, consent opens in the device browser and returns to Ojava only after the hosted callback has consumed its single-use, account-bound state. The app link carries only the connection outcome, never an authorization code or health token. On the web, the same callback returns to the exact allowlisted Ojava page.

This cloud connection is not available to users yet. Activation still requires the reviewed database migration, the Ojava-owned Google OAuth client and consent screen, exact production redirect registration, server-only deployment values, and live end-to-end verification. Until those checks pass, Ojava does not offer a new connection or sync action and file import remains the available web path. If activation is paused after an account was connected, its status stays visible and the user can still disconnect and revoke the stored authorization.

Future cloud aggregator adapter

Terra remains a possible future paid adapter for broad cloud coverage, not Ojava's current primary path or a live dependency. If activated later, its hosted authorization and webhook flow would stay read-only and consent-gated. The activation contract names the widget route, webhook target, signature check, patient reference binding, supported payload types, and review rails that must be verified before Ojava claims live cloud sync. Until then, Terra-backed providers are source-catalog entries rather than available account connections.

In the signed-in Ingestion workspace, the provider catalog lets you browse supported sources, search by app or device, and filter by category. Each card offers exactly one of three things: file upload for a live file lane, the connection manager for a source that has a real account path, or a plain note that the source is not available in Ojava. There is no request or notify-me action on an unavailable source, because saving a request never opened vendor authorization, stored credentials, or moved you closer to a connection. The same catalog powers source-acquisition planning, so Ojava can rank a useful next source path while preserving whether that path is file-ready, native-hub gated, cloud or partner gated, or unsupported.

For MyFitnessPal-specific setup questions, Ojava also keeps a reference-only marketplace freshness packet. The June 30, 2026 MyFitnessPal apps snapshot lists Fitbit, Garmin Connect, Strava, MapMyRun, and Runkeeper as featured entries. It preserves source-page labels such as Fitbit GET, Garmin Connect INSTALLED, and the Fitbit authorize URL as facts about MyFitnessPal's marketplace, not as proof that Ojava can open those authorization flows or that your Ojava account is connected to them.

Ojava Coach uses the same source setup readiness model when you ask which path fits a wearable, phone health hub, nutrition app, CGM, smart scale, or CSV export. It can say whether Ojava already has imported rows from that source, whether file import is ready today, or whether Apple Health, Health Connect, cloud sync, or a partner path is still activation-gated. It cannot perform external account actions, store source-app credentials, write back to another app, control devices, monitor in real time, or send alerts.

For CGM or glucose-source questions, the readiness model also checks whether Ojava already has imported blood-glucose rows, whether timestamped meals are missing for pattern review, whether a file export path is ready today, or whether native and partner connector rails are still gated.

For account-based sources such as Oura, WHOOP, Eight Sleep, Apple Health, Health Connect, and Terra, Ojava Coach can also explain the activation checklist before anything goes live: provider contracts or native entitlements, user consent scope, privacy and security review, source-quality checks, and webhook or import audit trails. That readiness packet is planning context only. It does not open OAuth, store source credentials, claim live sync, write back to sources, control devices, monitor in real time, send alerts, diagnose, treat, or make care decisions.

Provider-record network pull is a separate activation lane from wearable sync. Ojava now has an inert Persona plus Metriport path: Persona creates the hosted preliminary identity inquiry, Metriport runs its own identity and authentication sessions, and Metriport starts the record query only after both stages succeed. Other named record-network options remain catalog-only and expose no Connect action because Ojava has not implemented their provider-specific authorization, callback, and webhook runtime. Before Ojava creates a Persona inquiry, the signed-in records card explains that Persona will request a government ID and selfie, what bounded result Ojava keeps, what Ojava never stores, and how to refuse and keep using file import. A required checkbox records a purpose-specific consent receipt in the user's account, and the server independently requires the current receipt before any Persona inquiry or replacement link can be created. Persona and Metriport webhooks use separate secrets and verify the exact raw request body. Retrieved records still enter the same pending review queue, so nothing becomes clinical context until the user accepts it. The reviewed identity migration is live; retrieval now waits on provider accounts, server credentials, webhook setup, and full live verification. Until then, file import is the live path. Provider-record payloads can include bounded FHIR Specimen lab-provenance rows, Device source-context rows, and Provenance source-lineage rows for review. Specimen rows are portability and lab provenance only, not sample adequacy, lab validation, diagnosis, retest advice, collection instruction, care guidance, or lab ordering. Device and Provenance rows do not pair devices, activate live sync, monitor, alert, control hardware, validate authenticity, prove consent or chain of custody, decide source correctness, prove clinician review, complete clinical validation, or grant authorization.

For Ojava-held identity-verification data, Settings can stage a scoped deletion request while keeping the account. Staging the request is not immediate deletion. Ojava retains the consent receipt and bounded verification result in the account, but not the government-ID image or selfie.

When provider-record connections are present, the health data package can include a sanitized record-network lifecycle ledger. It shows connection status, sync freshness, ingest status, payload type, and staged row counts with local references only. It does not expose provider identifiers, aggregator user IDs, external event IDs, raw error messages, file URLs, identity documents, or raw FHIR payloads, and it does not turn the provider-record connector into live access.

Ojava also keeps a record-network activation diagnostics packet for the same lane. It separates selected connector setup, webhook ingest readiness, identity proofing, verified demographics, pending-review reuse, and lifecycle repair into ready-versus-gated rails. It is planning context only, not live provider access, identity proof, source correctness proof, auto-merge, diagnosis, treatment, emergency monitoring, coverage decisions, or legal advice.

Ojava also uses that same lifecycle evidence for source planning. If a connected provider-record source needs reauthorization, was revoked, has not synced recently, never synced, or had failed ingest events, Ojava ranks that repair work before suggesting another provider-record source. The repair packet is aggregate only: no provider names, raw ids, URLs, tokens, or raw error messages are shown to Coach.

The Ingestion source-governance packet also carries a network-readiness summary. It separates the visible catalog count, the 150,000+ provider-source architecture target, target provenance, the evaluated record-network options, and the configuration gates that still stand between planning and live record pull. This is transparency for source planning only: the target is a planning benchmark for the aggregator architecture, not a claim that every provider is already connected.

What you can import

The 340+ source entries below form a source catalog, not a count of live connections. Each entry is classified as file-ready, routed to the real native or Google connection manager, or labeled unavailable. Unavailable entries expose no inactive authorization or browser-only request button. File import is the broad live path today, and every eventual health-data connection remains read-only. Visit the public integrations page for the full provider list.

• EHR & hospital portals: Epic MyChart, Cerner portals, Apple Health Records, Metriport, Particle Health, Health Gorilla, Fasten, CommonWell, Carequality, 1upHealth, Human API, Redox, Kno2, Moxe, Zus Health, and other hospital patient gateways.
• National labs and lab platforms: Quest, Quest Health, LabCorp, Labcorp OnDemand, Function Health, Superpower, Empirical Health, Lifeforce, SiPhox Health, Everlywell, LetsGetChecked, Thorne, Mayo, specialty labs, and genetic testing services.
• Wearables and connected fitness: Oura, Fitbit, Garmin, WHOOP, Withings, Samsung, Strava, Polar Flow, TrainingPeaks, MapMyFitness, MapMyRun, MapMyWalk, MapMyRide, Renpho Health, Runkeeper, Concept2, Hydrow, Tonal, Ergatta, Aviron, Technogym, TrainerRoad, Runna, WorkOutDoors, Intervals.icu, ROUVY, FulGaz, MyWhoosh, Runalyze, Xert, Nolio, Tacx, Wattbike, Favero Assioma, 4iiii, Quarq, MySwimPro, Ride with GPS, Gaia GPS, and bridge apps.
• Sleep: Eight Sleep, Sleep Number, AutoSleep, Pillow, Sleep Cycle, Sleep as Android, SleepWatch, Tempur-Pedic, and sleep-tracking devices.
• Specialized devices: smart scales, blood-pressure devices, CGMs, body-temperature sensors, hydration sensors, metabolism trackers, HRV apps, and recovery apps through live file imports or activation-gated health-hub and cloud paths.
• Nutrition: MyFitnessPal CSV imports for reviewed Food Log rows, plus Cronometer, MacroFactor, Noom, YAZIO, Lifesum, MyNetDiary, Carb Manager, Samsung Health, Garmin Connect nutrition, FoodNoms, and food and macro trackers through file, health-hub, or partner paths.
• Fasting: Zero, Fastic, and intermittent-fasting logs.
• Cycle & fertility: Natural Cycles, Clue, Flo, Ovia, Glow, Premom, Mira, Tempdrop, Kindara, Apple Cycle Tracking, Samsung Cycle Tracking, and cycle-tracking apps.
• Genomics: 23andMe, AncestryDNA, Nebula, and genetic-testing services. Raw genotype and genetic-report uploads are labeled for sensitive review, not interpreted automatically.
• Microbiome: Viome, DayTwo, Thryve, ZOE-style gut-health tests, and microbiome-profiling labs. Microbiome reports are kept as report context, not scored or converted into diet advice; app membership, kit activation, and result access stay with the testing provider.
• Mental health apps: Headspace, Calm, How We Feel, Welltory, Sanvello, Daylio, Bearable, and meditation and wellness apps.
• Pharmacy: CVS, Walgreens, Amazon Pharmacy, GoodRx, SingleCare, Medisafe, MyTherapy, Dosecast, Walmart, Kroger, Cost Plus Drugs, Apple Health Medications, Samsung Health Medications, and pharmacy-history exports.
• Imaging: Hospital imaging CDs, PocketHealth, Ambra, PowerShare, lifeIMAGE, and imaging-exchange networks.
• Insurance: Insurance portals, eligibility summaries, and claims records.
• Research: All of Us Research Program, UK Biobank, and research-study data.

Want to add a new data source?

If you use an app or device that stores health data and want to bring it into Ojava, check whether it offers an export function (CSV, PDF, FHIR, or API). If it does, you can import it today via the Ingestion drop zone. If it doesn't, let us know and we can explore adding it to our aggregator roadmap.

Your data, your control

Every import is consent-gated, read-only, and filtered to only the data you approve. You decide what to accept into your record and can delete anything at any time. Ojava does not use your health data to train AI models, does not track your behavior across apps, and does not sell your data to advertisers or data brokers. See Privacy & your data for the full picture.