Skip to main content
This guide assumes your organization, event types, and API keys are already configured (Console and/or CLI; see Setup). Here we wire your codebase to the Olira SDK: initialize the client, register one or many patients, and emit logs that drive patient state.

Install tooling

CLI (optional: keys, login, MCP config):
SDK (required for ingestion from your backend):

Authenticate in your service

Use an API key with at least sdk:event-log and api:manage-patients for creating patients and logging. Create the key in the Console or with olira keys create (see the CLI key commands). Store it in a secret manager and pass it at runtime:

Initialize the SDK and create patients

Single patient

Multiple patients

Use create_patients_batch / CreatePatientsBatch to register up to 500 patients in one POST /v1/patients/batch call. Pass a list of CreatePatientRequest objects; the response is a PatientBatchResult with successes and per-index errors; partial success is supported.
Build the request list from a comprehension, a CSV import, or any iterator. For a single registration you can still use create_patient / CreatePatient. Anchor rules and field shapes match CreatePatientRequest in the SDK reference.

Log data

Send structured logs with an OliraLogType and a payload that matches that type (see the log types catalog). Use the correct patient id for each log. log() is a tap: it enqueues and returns immediately, so you can emit from inside a request or workflow without waiting on Olira. It has no idempotency_key — if that path runs twice, you get two events.
log_batch() sends immediately and returns accepted / failed. Use it when you need the write confirmed, or when you might retry the same call — set idempotency_key to a stable id you own (your record id is a good choice). See Retries and idempotency.
Use log_fhir() when your source data is already FHIR R4. It is a confirmed write like log_batch — pass idempotency_key the same way if you might retry. Optional OliraTrace links a log to an object in your system (conversation id, questionnaire id, etc.) for provenance in observability and when reading state later.

Verify ingestion

When your organization has observability enabled, use Observability → Logs and Events in the Console, and Patient detail to confirm modules and views update as expected. See Console observability.