Results that live only in a portal make work for everyone: someone re-keys them into the clinic system, someone else chases what changed overnight. This page is a developer-facing overview of the Catenix API, enough to plan an integration before you have credentials in hand. It is a read-only reporting API served over HTTPS, with per-clinic keys, signed webhooks, FHIR R4 pull and transparent usage metering, so your own systems can read what the platform records without polling and without re-keying.
Per-clinic API keys
Access is issued per clinic organisation during onboarding. Each key reaches your own data only, is scoped to the categories you ask for (results but not patients, for example), carries its own request-rate limit, and can be revoked at any time. The key itself is shown once at issue: Catenix stores only a salted hash, the way it treats passwords.
A read-only reporting API
The API exposes the platform's core records as resources, read-only. We describe the categories here rather than specific paths, because endpoint names and fields are confirmed against the live reference during onboarding:
- Patients & encounters: the people being tested and the visits that group their results.
- Orders: what has been requested for an encounter.
- Results: values, units and the analyser-supplied status and flags, carried verbatim, with review and release state.
- Devices & fleet status: connected analysers with a computed online or offline status.
- QC: quality-control runs and lockouts captured alongside the results they govern, for statistical data-quality monitoring.
- Sites: the clinics and locations your records belong to.
- Usage: your own month-to-date API usage, readable at any time.
Signed webhooks
Rather than polling, your system can subscribe to events: a result arriving or being released, a QC failure or lockout, a device going offline or coming back, a report being released. Every delivery is signed with a per-subscription secret, so your endpoint can verify a message really came from Catenix before trusting it, and failed deliveries are retried on a backoff schedule. The shape below shows roughly what a delivery looks like, useful for picturing the data, not for building against. Field names and structure are confirmed in the live reference:
// Illustrative delivery, not the live schema X-Catenix-Event: result.created X-Catenix-Signature: sha256=<hmac-of-raw-body> { "event": "result.created", "created": "<utc-timestamp>", "data": { "id": "<opaque-id>", "analyte": "GLU", "value": "5.4", "unit": "mmol/L", "status": "final" } }
FHIR R4 pull
Clinic groups that run an EHR or a laboratory information system can pull records over FHIR R4, the standard those systems already speak, using the same clinic-scoped key: patients, observations and diagnostic reports, read-only. Results join the record your clinicians already use rather than living in a second window, and HL7 v2 delivery into an existing LIS remains available alongside.
Usage metering
Every API call is counted per clinic per day, and your month-to-date figure is readable through the API at any time: you see the same number we do. Where your plan includes an API allowance, that is the figure it is measured against.
Integration patterns
Most integrations fall into one of three shapes, depending on who is building:
IVD manufacturers: stream device data in
If you make analysers, the goal is usually to get device output into Catenix cleanly and have it appear with full traceability. That is the connectivity layer's home ground: standards-based capture over the protocols your instruments already speak, with results carried through verbatim. See the IVD manufacturers page and how device connectivity works.
Distributors: white-label and connect catalogues
Distributors typically connect a portfolio of devices and present the platform under their own brand. The API supports onboarding catalogues and connecting fleets across the clinics you serve. See the distributors page for how that partnership works.
Clinic groups: pull results into an existing LIS or EHR
Groups that already run a laboratory information system or EHR usually want POCT results to land there. Catenix delivers over HL7 v2 into an existing LIS and is FHIR-friendly for EHR integration, so results join the record your clinicians already use rather than living in a second window. The devices & integrations page lists the standards involved.
Where interpretation stops
Every resource and every webhook carries data faithfully: value, unit, and the analyser-supplied status and flags, untouched. The API does not interpret results, re-calculate values or emit clinical alerts. Interpretation and decision-making remain with the clinician and the systems they authorise; Catenix moves the data and records the trail.
Getting access
The full API reference, exact endpoints, schemas, authentication detail and webhook event types, is shared during onboarding. To get started, request access through our team and we will scope the integration with you.
Questions, answered
What developers ask first.
How does authentication work?
The API is served over HTTPS and uses per-clinic API keys. Each key is issued during onboarding, scoped to your organisation and to the data categories you need, and can be revoked at any time. The key is shown once at issue and stored only as a salted hash. We share the exact scheme and key lifecycle as part of the integration documentation.
Do you support webhooks for result events?
Yes. Alongside the REST resources you can subscribe to events such as a result arriving or being released, a QC failure, or a device going offline, so your system is notified rather than having to poll. Every delivery is signed with a per-subscription secret so you can verify it came from Catenix, failed deliveries are retried, and payloads carry the data verbatim with no interpretation of clinical values.
Can we pull results into our existing LIS or EHR?
Yes. Clinic groups commonly read results from the API, receive them over HL7 v2 into an existing laboratory information system, or pull them over FHIR R4 into an EHR. We scope the exact feed with you and share the full reference during onboarding.
Build on a clean feed.
Tell us what you're connecting and we'll share the reference and scope the integration with you.