Adapters
Adapters are prebuilt Linkiir nodes that connect a workflow to an external system. Each one arrives as a node template plus the code library behind it, so you add it from the palette and fill in fields rather than writing a client from scratch.
You configure credentials, endpoints, and what to fetch or send. The connection work — authentication, token refresh, request signing, retries, error reporting — is already done.
Requesting the Adapters package
Adapters are supplied separately from the Linkiir installation. To request them for your environment, email support@linkiir.com with your Linkiir version, your platform, and the systems you need to connect to.
You receive either a catalog to subscribe to, which keeps its adapters updatable in place afterwards, or a project to import with the templates and libraries already attached to the nodes that use them. See Catalogs and Project Import and Export.
Available adapters
By category
| Adapter | Connects to | Palette group | Library |
|---|---|---|---|
| Epic | Epic FHIR endpoint | Source Custom | epic_fhir |
| Cerner | Cerner FHIR endpoint | Source Custom | cerner_fhir |
| eClinicalWorks | eCW FHIR endpoint | Source Custom | ecw_fhir |
| ModMed | ModMed FHIR endpoint | Source Custom | modmed_fhir |
| Athena Health | Athena Health platform | Source Custom | athena_health |
| Dexcom CGM | Dexcom CGM account | Source HTTP, Source Custom | dexcom_cgm |
| PointClickCare | PointClickCare organization | Source Custom, Transform Custom | pcc_api |
| Salesforce | Salesforce REST API | Transform Custom | salesforce |
| Dynamics 365 | Microsoft Dynamics 365 CRM | Source Custom | dynamics_crm |
| AWS S3 | S3 and S3-compatible storage | Source Custom, Transform Custom, Source HTTP | aws_s3 |
| Slack | Slack workspace | Transform Custom | slack |
| Azure OpenAI | Azure OpenAI deployment | Transform Custom | azure_openai |
| FHIR Resource Creator | Nothing — local transformation | Transform Custom | fhir_resource |
| FHIR Profiling Tools | Nothing — local HTTP service | Source HTTP | fhir_profiling |
Start here
| If you want to | Read |
|---|---|
| Understand how an adapter is delivered and configured | How Adapters Work |
| Pull patient data from an EHR | Epic, Cerner, eClinicalWorks, ModMed, Athena Health |
| Read glucose data from a CGM device | Dexcom CGM |
| Read or write records in long-term care | PointClickCare |
| Read or write records in a CRM | Salesforce, Dynamics 365 |
| Move messages through object storage | AWS S3 |
| Send an alert to a channel | Slack |
| Send message content to a model | Azure OpenAI |
| Build or inspect FHIR resources locally | FHIR Resource Creator, FHIR Profiling Tools |
What every adapter has in common
- Fields, not code. Endpoints, credentials, and what to fetch are node configuration. See How Adapters Work.
- Live Mode. A switch that lets the node authenticate and log what it would send, without sending it. Use it for the first run of every adapter.
- Verify TLS on by default. Certificate verification stays on unless you deliberately turn it off for a local test proxy.
- Secrets stored as masked fields. Passwords, API keys, and secret keys are encrypted in the project and never written to logs. Private keys stay on disk and are referenced by path.
- Errors in the node log. Each adapter reports a stable error code and a readable message, listed on its page.
Point a new adapter at the vendor's sandbox or test environment, with synthetic data, before connecting it to production. See Sample Code for the practices the demo interfaces follow.