Build health agents on standardized health data

Mirobody API turns messy health data into standardized, AI-ready records — and gives you two OpenAI-compatible surfaces to put agents to work on them. It’s the managed layer over the open-source Mirobody engine: we host storage, models, and keys; you point an OpenAI SDK at the base URL with an mb_live_* key.

The loop: upload → standardize → use with AI

Upload anything

Structured readings via POST /v1/data, lab PDFs / photos / spreadsheets via POST /v1/files (OCR included) — per end-user, fully isolated Subjects.

Standardization happens on every write

Names resolve to LOINC deterministically (no LLM code-guessing), values normalize to UCUM units, every reading gets a FHIR mirror. "血糖(空腹)", "FBG" and "Glucose, fasting" become one series. See Standardization.

Put AI on top

Ask the Answers API for a grounded, evidence-cited answer — or build a full agent on the Agent API with your own tools, stored conversations, and the openai-agents SDK working out of the box.

Three shapes of data, one door each

Health data arrives in three shapes — each has exactly one door in:

Data shape	Typical source	How it goes in	Endpoint
Structured readings	Devices / wearables (you integrate them, write daily aggregates), manual entries	Structured records	`POST /v1/data` — pre-aggregate high-frequency samples; episodes (sleep, workouts) carry `time` + `end_time`. See the device-data cookbook.
Files / photos	Lab reports, checkup PDFs, phone photos	File upload	`POST /v1/files` — OCR + parsing included; `POST /v1/extract` when you want the parsed readings back synchronously
Narrative notes	”dizzy and a headache”, dictated notes	Narrative text	`POST /v1/extract` — quantifiable readings are extracted; pure narrative returns `data: []` plus a `note` (a journal endpoint is on the roadmap)

Mirobody hosts, standardizes and serves the data to AI — collecting it (device OAuth, app capture) is your side of the line.

Two API surfaces, one engine

Agent API — recommended

POST /v1/responses (OpenAI Responses-compatible). Your function tools, previous_response_id / session_id state, response.* streaming. The openai-agents SDK works by changing only the base URL.

Answers API

POST /v1/chat/completions. A closed grounded completion — one question, one evidence-backed answer. Drop-in for any OpenAI SDK, and ideal as a tool inside your own agent.

Not sure? Choose your API in one minute.

Why Mirobody

Grounded, not plausible — answers come from the Subject’s real records, with health_records / citations evidence and a full server tool trace.
Standardized by default — LOINC + UCUM + FHIR on every write; your analytics and the agent read the same clean series. Dry-run any document with POST /v1/extract.
OpenAI-compatible twice over — Chat Completions and Responses protocols; existing SDKs and agent frameworks just work.
Multi-tenant by design — one key, an isolated Subject per end-user; per-Subject right-to-be-forgotten deletes.
Open at the core — the same engine is open source; self-host it whenever you want.

Three ways to run Mirobody

Hosted API (this platform) — an mb_live_* key against our managed clusters; storage, models, and keys are run for you. Start with the Quickstart.
Self-host the SDK — pip install mirobody and run the engine inside your own infrastructure, bringing your own PostgreSQL + Redis.
Open source — git clone the Mirobody engine and stand up the full stack yourself with deploy.sh.

Start here

Quickstart

Key → data → standardized records → your first agent, in minutes.

Choose your API

Answers vs Agent — the one-minute decision.

API Overview

Auth, multi-tenancy, retention, errors, every endpoint.

Regions

Which cluster to use and what’s live today.

​The loop: upload → standardize → use with AI

​Three shapes of data, one door each

​Two API surfaces, one engine