> ## Documentation Index
> Fetch the complete documentation index at: https://docs.olira.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# How logs work

> What happens when you submit a log, the fields on every submission, and the difference between lifecycle-tracked logs and point-in-time records.

Every health data point you send to Olira is a log. When you submit logs via `POST /v1/logs/batch`, Olira:

1. Validates the `log_type` field (log type) against the platform catalog
2. Validates the `payload` against that log type's JSON schema
3. Writes each record to the log store
4. Optionally appends to the TEMP segment of matching view templates

<Note>
  Your organization's platform configuration controls which log types are
  accepted. Only log types you selected during onboarding are active;
  submitting an unlisted type returns `403`.
</Note>

## Sending a log

<CodeGroup>
  ```python Python theme={null}
  from olira import OliraClient, OliraLogType

  client = OliraClient(api_key="YOUR_API_KEY")
  client.log(
      log_type=OliraLogType.SYMPTOM_REPORT,
      patient_id="8a4fde23-0f1b-4c2a-9d7e-b36c1a5f0e82",
      payload={
          "instrument": "esas_r",
          "symptoms": [
              {"name": "pain", "score": 4},
              {"name": "fatigue", "score": 6},
          ],
      },
  )
  ```

  ```http HTTP theme={null}
  POST /v1/logs/batch
  Authorization: Bearer YOUR_API_KEY
  Content-Type: application/json

  {
    "logs": [
      {
        "log_type": "symptom_report",
        "patient_id": "8a4fde23-0f1b-4c2a-9d7e-b36c1a5f0e82",
        "timestamp": "2026-03-18T09:00:00Z",
        "payload": {
          "instrument": "esas_r",
          "symptoms": [
            { "name": "pain", "score": 4 },
            { "name": "fatigue", "score": 6 }
          ]
        }
      }
    ]
  }
  ```
</CodeGroup>

| Field             | Required | Description                                                                                         |
| ----------------- | -------- | --------------------------------------------------------------------------------------------------- |
| `log_type`        | Yes      | Log type (e.g. `symptom_report`); REST JSON key `log_type`                                          |
| `patient_id`      | Yes      | Olira-assigned `patient_id`                                                                         |
| `payload`         | Varies   | Log `payload` (schema depends on log type); see the [catalog](/reference/log-types/symptom-reports) |
| `timestamp`       | No       | ISO 8601 when the observation occurred; defaults to ingestion time if omitted                       |
| `log_id`          | No       | UUID for deduplication; auto-generated if omitted                                                   |
| `idempotency_key` | No       | Duplicate submissions with the same `idempotency_key` are silently ignored                          |
| `trace`           | No       | Link to an object in your system: `{ "object_type": "...", "object_id": "..." }`                    |

Send multiple logs in one request by adding objects to the `logs` array. Each object is one log.

## Lifecycle-tracked logs vs. point-in-time records

Log types marked **lifecycle** create or update a *persisted entry* in patient state, carrying a status (`active`, `resolved`, `remission`, …), an effective time window, and a full audit trail of transitions. **The entry does not resolve itself with the passage of time.** You must explicitly close it by logging a follow-up event. For example, a symptom logged with a score above zero becomes `active`; it only becomes `resolved` when you log the same symptom again with `score: 0`. An alert created via `care_action` stays active until you re-log the same `entry_key` with `status: "resolved"`. Conditions, allergies, devices, and procedures follow the same pattern; each is active until you log `action: "remove"` or a terminal `clinical_status`.

Log types without the lifecycle marker are *immutable records*. Each event is an independent observation appended to a rolling window: a vital sign reading, a lab result, a sleep session, a conversation transcript. There is nothing to "resolve"; older records naturally age out of the active window. Use these to capture what happened, not to track an ongoing clinical state.

## Catalog

Browse payload schemas, required fields, and source information for all supported log types in the [log types catalog](/reference/log-types/symptom-reports).