Getting Started
Introduction to Mirobody
What Mirobody is, the three stages it runs, and how to choose between Mirobody Cloud and self-hosting.
What is Mirobody?
Section titled “What is Mirobody?”Mirobody is a health data engine. It takes readings from any source — lab reports, wearables, genetic tests, imaging — resolves each one to a canonical code, and stores it as a comparable record an AI can reason over.
The name is short for Mirror Your Body in Data: one standard for every source, so a person’s numbers accumulate into a single comparable record instead of a dozen incompatible exports.
The engine is open source, Apache 2.0 licensed. Mirobody Cloud is its hosted form: we operate the storage, the models and the keys, and expose the whole thing behind an OpenAI-compatible /v1 API, so an existing OpenAI SDK reaches it by changing a base URL and a key. Standardization of structured readings is the same on both. If you would rather run it on your own infrastructure, that is the Open Source tab.
The fastest path to a working call is the Quickstart: create a key, write one record, ask one question.
The three stages: Collect, Standardize, Answers
Section titled “The three stages: Collect, Standardize, Answers”The engine does three things — ① Collect → ② Standardize → ③ Answers — and Cloud is the same three, with the operational half handled for you. One difference matters: on Cloud, collection happens on your side. You obtain the data (device OAuth, in-app capture, a user uploading a report) and hand it to us; we host, standardize and serve it.
Collect — match the endpoint to your data shape
Structured readings go to POST /v1/data. Lab PDFs, photos, and spreadsheets go to POST /v1/files, which stores the original, extracts its text, and standardizes any readings it finds. POST /v1/standardize runs that same standardization synchronously — for a dry-run preview, or on narrative text.
Standardize — every structured reading, automatically
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.
Answers — put AI on top
Ask the Answers API for a grounded, evidence-cited answer — or build a full agent on the Agent API: your own tools, stored conversations, and the openai-agents SDK working out of the box. Answering is the most direct use of standardized data, and the same records are what let you mine insights, generate a report, or raise an alert.
Choose how you run Mirobody
Section titled “Choose how you run Mirobody”Nothing to install. Create an mb_live_* key in the console and call the OpenAI-compatible /v1 surface on our managed clusters.
Run the open-source engine on your own infrastructure — git clone, ./deploy.sh — and the data never leaves your machines.
Both run the same three stages and the same standardization. They differ in who operates the storage and the models, and in the API each exposes: /v1 on Cloud, /api/* plus an /mcp endpoint when you self-host.
Two API surfaces, one engine
Section titled “Two API surfaces, one engine”POST /v1/responses (OpenAI Responses-compatible). Your function tools, previous_response_id / session_id state, response.* streaming. The openai-agents SDK needs only a new base URL.
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.
Four shapes of data, four endpoints
Section titled “Four shapes of data, four endpoints”These are the same three sources the console’s Data page offers, plus the journal case.
| Source | Endpoint |
|---|---|
| Files / photos — lab reports, checkup PDFs, phone photos | POST /v1/files |
| Structured records — device and wearable data above all, plus manual entries | POST /v1/data |
| Narrative text — a note or a report with readings inside it | POST /v1/standardize |
| A purely subjective journal entry | POST /v1/responses with store: true |
Which endpoint fits which case, with worked examples, is in the Quickstart.
Why Mirobody
Section titled “Why Mirobody”- Grounded, not plausible — answers can include
health_records,citations, and the server tool steps used to gather evidence. - Standardized structured data — LOINC + UCUM + FHIR on records written through
/v1/dataor stored by/v1/standardize; your analytics and the agent read the same series. - 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 — Cloud runs the same open-source engine, organized around the same three stages. Self-host it and ① Collect becomes ours too: device providers pull on a schedule, and the terminology layer runs offline inside your own process. See The Engine as a Library.
Start here
Section titled “Start here”Key → data → standardized records → your first agent, in minutes.
Answers and Agent — how to choose between the two surfaces.
Auth, multi-tenancy, retention, errors, every endpoint.
Which cluster to use, and what is live in each.
For agents and scripts, the whole site is also published as plain text: /llms.txt indexes every page, and /llms-full.txt is the full corpus in one file.