Developer journeys
API & SDK capability map
Find the Mediloop API, SDK, connector, healthcare standard or event surface that matches the capability you need.
How to use this map
Start with the capability you want to add, then choose the developer surface that matches the external system and the workflow. A surface can be a REST or FHIR endpoint, a healthcare protocol operation, an SDK method, a connector configuration or an event subscription. Not every capability should invent a REST endpoint.
Important
Documentation examples and protocol mappings do not imply production availability. Use API Reference and product status labels to confirm the implemented contract and onboarding requirements.
Platform APIs
| Capability | What you can do | Primary developer surface | Documentation |
|---|---|---|---|
| Identity & SSO | OAuth 2.0 / OIDC / identity APIs | REST + identity protocols + SDKs | Identity docs → |
| Organizations, users & permissions | Tenant, membership, role and scope management | REST APIs | Organizations → |
| Scheduling | Appointments, slots, resources and availability | REST / FHIR-aligned resources | Scheduling → |
| Teleconsultation | Session and workflow integration | Platform APIs / events | Teleconsultation → |
| Prescriptions | Create, sign, route and track prescription workflows | REST + FHIR MedicationRequest/MedicationDispense | Prescription API → |
| Marketplace / supplier / procurement | Catalogues, products, listings, orders and commercial workflows | REST + webhooks | Marketplace API → |
Healthcare interoperability
| Domain | Common operations | Primary standards / surfaces | Documentation |
|---|---|---|---|
| General clinical data | Search, read, create and update supported healthcare resources | FHIR R4/R5 profiles + REST | FHIR API → |
| Laboratory | Orders, specimens, analyzer/LIS exchange, observations and reports | HL7 v2, FHIR, ASTM/vendor protocols, Connector SDK | Laboratory Connectors → |
| Medical imaging | Worklists, query/retrieve/store, studies, instances and reports | DICOM, DICOMweb, FHIR ImagingStudy/DiagnosticReport | Imaging Connectors → |
| Clinical devices | Capture observations, events, local resources and selected commands | IEEE 11073, BLE/GATT, USB/Serial, vendor SDKs, FHIR | Clinical Devices → |
Connector surfaces
Connector SDK
Build custom adapters and handlers when an existing standard or prebuilt connector is not enough.
Explore documentation →
Workstation Agent
Reach local devices, drivers, files or native resources that a browser cannot safely access directly.
Explore documentation →
Protocol connectors
Connect systems using healthcare and enterprise protocols while preserving retries, mapping, audit and observability.
Explore documentation →
Events and automation
| Need | Surface |
|---|---|
| React to resource or workflow changes | Webhooks / subscriptions / event stream |
| Avoid repeated polling | Event-driven notifications with retry semantics |
| Coordinate long-running integrations | Async workflow + correlation IDs + idempotency |
| Track connector/device health | Health endpoints, metrics and connector status events |
Integration surface rules
REST / FHIR endpoint
Use when a developer calls a Mediloop service or healthcare resource directly.
Protocol operation
Use DICOM, HL7, ASTM, MQTT or other native protocols when they are the correct integration contract.
SDK method
Use an SDK when it reduces implementation boilerplate while keeping the underlying API contract explicit.
Connector / configuration
Use configuration and adapters when the capability is driven by infrastructure rather than an application request.
Event / webhook
Use for asynchronous state changes and near-real-time workflow notifications.
No direct API
Architecture, governance or operational guidance may intentionally have no direct callable endpoint.
Availability and versioning
Treat the API Reference as the authoritative contract for implemented HTTP endpoints.
Use status labels such as Available, Beta, Planned or country-specific onboarding required.
Version SDKs and APIs independently from frontend frameworks.
Expose migration notes and deprecation windows when contracts evolve.
Preserve standards version information for FHIR, DICOM/DICOMweb, HL7 and connector profiles.
Do not present illustrative documentation examples as live production endpoints until the backend contract exists.