The API is not a export hatch bolted onto the side. It is the same contract layer the product itself is built on — which is why it is complete, versioned, and does not lag the interface.
Surface
Every route under /api/v1 with a standard error envelope, correlation IDs, cursor pagination and idempotency keys on mutating operations. OpenAPI generated from code, so it cannot drift from reality.
A TypeScript SDK generated from the same OpenAPI document, versioned alongside the API.
A typed registry of every domain event — name, version, payload schema, owning module — exposed as HMAC-signed webhooks with a full delivery log.
Patient, Encounter, Condition, Observation, MedicationRequest and more, over a standard FHIR R4 read and search API.
Modules declare their extension points explicitly. You build against a published contract rather than reverse-engineering internals.
Payments, billing, admissions, orders, claims and booking all require idempotency keys, so a retry cannot double-charge or double-admit.
Full API documentation, the event catalog and the SDK are published as the corresponding modules complete — see the phase plan for where each sits. We would rather publish documentation that matches shipped behaviour than a specification that gets corrected later.
Integration
Each connector declares its own configuration schema, so onboarding one is a configuration exercise rather than an engineering programme.
Next step
An executive demonstration takes forty-five minutes. We seed a hospital with synthetic data shaped like yours, put the digital workforce on duty, and answer the hard questions with the architecture open.
synthetic data · zero real patients
self-hosted or managed cloud
one database per hospital