Data - Mirobody

Write structured records straight into a Subject’s store, and read them back. Every write runs through the platform’s standardization pipeline — records come back with a LOINC code, canonical name, UCUM-normalized value/unit, and a FHIR mirror. The chat agent reads this same data with its built-in tools. 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.

The user field is the tenant-isolation key. The backend maps (your account, user) to an internal Subject; each user you pass is fully isolated from the others. Pass each end-user’s stable id and their data never crosses over. Omit it and the call falls back to your account’s default Subject. Subjects are invisible to the Mirobody web app and to other developers. The user value is normalized (trimmed + lowercased) before mapping, so Alice and alice resolve to the SAME Subject — pass a stable, canonical id.

Write records

POST /v1/data
Authorization: Bearer mb_live_*
Content-Type:  application/json

Field	Type	Description
`records`	array	Each record `{indicator, value, unit?, time?, end_time?, source?}`. Max 500 records per request. `end_time` (optional, ISO time) marks the end of an episode — sleep, workouts — whose start is `time`. `measured_at` / `start_time` are accepted as aliases for `time` — rows from POST /v1/extract (which returns `measured_at`) can be forwarded as-is.
`user`	string	Subject the records belong to (tenant-isolation key).
`retention`	string	Required — there is no default. One of `permanent` / `1h` / `2h` / `6h` / `1d` / `session` (`persistent` is accepted as an alias of `permanent`). Hour grains auto-delete after that long (hard-capped ≤ 24h). Omitting it — or sending any value outside the enum — returns `400` (`code: invalid_retention`).
`session_id`	string	Required when `retention=session` (`400`, `code: invalid_session`, otherwise). Tags the records so `DELETE /v1/sessions/{id}` can purge them.

curl https://mirobody-api.thetahealth.ai/v1/data \
  -H "Authorization: Bearer $MIROBODY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
        "user": "alice",
        "retention": "permanent",
        "records": [
          {"indicator": "fasting_glucose", "value": 5.4, "unit": "mmol/L", "time": "2026-06-16T07:30:00Z"},
          {"indicator": "fasting_glucose", "value": 5.1, "unit": "mmol/L", "time": "2026-06-17T07:25:00Z"}
        ]
      }'

Response — standardized counts the records that resolved to a LOINC code on the way in:

{ "status": "ok", "ingested": 2, "standardized": 2, "subject": "alice" }

Every write is standardized, not just stored. Each record’s value/unit is UCUM-parsed and its indicator name resolved to LOINC deterministically (curated corpus + embedding — no LLM guessing). See Standardization. To preview that pipeline without writing anything, use POST /v1/extract with store=false.

Episodes (sleep, workouts)

Episode-type records span a period rather than a point in time — put the start in time and the end in the optional end_time:

curl https://mirobody-api.thetahealth.ai/v1/data \
  -H "Authorization: Bearer $MIROBODY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
        "user": "alice",
        "retention": "permanent",
        "records": [
          {"indicator": "sleep_duration", "value": 7.5, "unit": "h",
           "time": "2026-07-09T23:10:00Z", "end_time": "2026-07-10T06:40:00Z",
           "source": "garmin"}
        ]
      }'

Writing device data at scale (daily aggregation, batching, vendors)? See the device-data cookbook.

Read records

GET /v1/data?user=alice&indicator=fasting_glucose&limit=100
Authorization: Bearer mb_live_*

Query	Description
`user`	Subject to read from.
`indicator`	Optional filter by indicator name (substring match).
`limit`	`1`–`1000` (default `100`).
`offset`	Skip N records for paging (ordering is stable: newest first). `has_more: true` → request the next page with `offset += limit`.

The response is an OpenAI-style list, newest first. value is the human-readable string (e.g. "5.4 mmol/L"); the machine-readable fields ride alongside:

{
  "object": "list",
  "data": [
    {
      "id": 1287,
      "indicator": "fasting_glucose",
      "value": "5.4 mmol/L",
      "parsed_value": "5.4",
      "parsed_unit": "mmol/L",
      "loinc_code": "1558-6",
      "canonical_name": "Fasting glucose [Mass/volume] in Serum or Plasma",
      "fhir_resource_id": "8f3c9a1e-...",
      "time": "2026-06-16T07:30:00+00",
      "end_time": null,
      "source": "api",
      "comment": ""
    }
  ],
  "has_more": false,
  "subject": "alice"
}

Field	Description
`data`	The records (up to `limit`).
`id`	Row id (integer) — pass it to `DELETE /v1/data?id=` for a row-level delete.
`value`	Human-readable reading (string).
`parsed_value` / `parsed_unit`	Numeric value + UCUM unit from the standardization pipeline (`null` when unparseable).
`loinc_code` / `canonical_name`	Deterministic LOINC resolution + its display name (`null` when the name didn’t resolve).
`fhir_resource_id`	Id of the record’s FHIR Observation mirror.
`end_time`	End of the period for episode records (sleep, workouts); `null` for point-in-time readings.
`source` / `comment`	`source` reports the WRITE CHANNEL (`api`, `extract`); your free-text origin tag from the record’s `source` field is returned in `comment`.
`has_more`	`true` when this page hit `limit` — fetch the next page with `offset += limit`.
`subject`	The Subject the records belong to (resolved from `user`).

Erase records

DELETE /v1/data?user=alice&indicator=fasting_glucose
Authorization: Bearer mb_live_*

Hard-deletes the Subject’s records — right-to-be-forgotten semantics (rows physically removed, not flagged). Three scopes, from narrowest to widest:

Query	Scope
`id`	Exactly one row — the integer ids `GET /v1/data` returns. Takes precedence over `indicator`.
`indicator`	One indicator (substring match, mirroring the GET filter).
(neither)	All of the Subject’s records.

DELETE /v1/data?user=alice&id=1287

{ "status": "ok", "deleted": 1, "subject": "alice" }

To erase everything about a Subject (records + files + conversations + the identity mapping), use DELETE /v1/subjects/{user} — see Compliance.

Use-and-forget data

There is no retention: "none" — writing to the store while asking not to store is contradictory, and the value is rejected like any other non-enum value. Two clean patterns instead:

Dry-run analysis, zero side effects — POST /v1/extract with store=false (the default): standardization results out, nothing written.
Short-lived working data — write with retention: "1h", or retention: "session" + a session_id you delete when done.

​Write records

​Episodes (sleep, workouts)

​Read records

​Erase records

​Use-and-forget data

Write records

Episodes (sleep, workouts)

Read records

Erase records

Use-and-forget data