Skip to main content
The ClinikEHR API lets software you build talk to ClinikEHR, the records system clinics, pharmacies and laboratories use. Your program sends an ordinary web request, and gets back plain JSON: a clinic’s stock, a patient’s allergies, an appointment, and more. You can also send information back for the clinic to review.
This API is under active development. The sections below say, resource by resource, what you can call today. A page that describes something not yet available says so at the top, in its own banner — nothing on this site describes a defect as if it were a feature.

​
How it works

1

Get a key

A key is a long secret string, like a password for your program. A clinic creates one for you, or you create your own in the developer portal. See Getting a key.
2

Send it with every request

Put the key in the Authorization header. That is the only sign-in this API has.
3

Read or send data

Call an endpoint, such as GET /v1/clinics/{clinic_id}/inventory/items, and read the JSON that comes back.
Here is a complete request. It asks the API which clinic or workspace your key belongs to:
New here? Start in the sandbox. Sign up for a developer portal account and you get a test key straight away. It reaches only a sandbox of invented data, so you can try the examples on this site without touching a real clinic. Then follow the Quickstart.

​
Two ways to use this API

Both kinds send the same Authorization: Bearer header, hit the same base URL, and get the same responses for the same resource — see Authentication.

​
What you can build

Inventory and stock

Read a clinic’s catalogue, stock and availability, and record stock changes.

Patient records

Patients, visits, notes, allergies, conditions and medicines, with the clinic’s permission.

Referrals and outside care

Send referrals for a clinic to review, and read the ones it received.

Insurance

The payers a clinic works with, and a patient’s coverage.

Insurance for HMOs

Verify enrollees, vet claims, decide authorizations and report payments, or submit claims for a clinic.

Connections to clinics

Ask a clinic for access with a one-time code, and find listed pharmacies.

FHIR

Read clinical records in the FHIR R4 standard.
Every endpoint, with its request and response, is in the API reference tab.

​
Patient information

Anything about a patient (records, appointments, notes, allergies, medicines, referrals, insurance and drug requests) needs more than a key, because it is protected health information. The clinic must agree, and the key must be allowed to carry patient-data permissions. Getting access to patient data lists exactly what is needed. A test key can try all of it in the sandbox today.

​
What’s available now

  • Inventory, for a clinic your key reaches: locations, catalogue items, availability bands, and exact stock — see Inventory and Stock bands. Creating an item, receiving or adjusting stock, and recording a transfer are also live, with the same key — see Retries and duplicates for the idempotency design every write uses.
  • Insurance: the payers a clinic has enabled, and a patient’s coverage, which you can read and add (a coverage you add stays inactive until staff confirm it). It needs the same patient-data access as the records below. See Insurance.
  • Insurance for HMOs and insurers: for a clinic outside the United States, the insurer the clinic links to your organization: its enrollees, plans, claims and authorization requests, which an insurer can vet, decide and report payments against, and which a developer can submit. The clinic decides what each connected organization is. It needs patient-data access. See Insurance for HMOs and insurers.
  • Allergies: a patient’s allergies and intolerances, which you can read and send for a clinician to review. They need the same patient-data access as the records below. See Allergies.
  • Referrals: the referrals a clinic has received for a patient, which you can read and send for the clinic to review. The clinic alone accepts, declines or books them. They need the same patient-data access as the records below. See Referrals.
  • Medications: the medicines a patient reports, which you can read and send for a clinician to review, and the prescriptions written for them, which are read-only. They need the same patient-data access as the records below. See Medications.
  • Automatic acceptance: a clinic can choose to accept new allergies, conditions, reported medicines or referrals from your key or connection without review. The answer then already shows review_status: "confirmed" and accepted_automatically: true. See Automatic acceptance.
  • Providers: the clinic’s clinical staff directory (name, role, specialty, NPI and licence), which is read-only and holds no contact details. See Providers.
  • Outside care providers: the doctors, referrers and specialists a patient names, which you can read and add, and change or remove when your app added them. They need the same patient-data access as the records below. See Outside care providers.
  • Encounters: a patient’s visits as the clinic documents them, which you can read, and open as a draft visit for a clinician to complete. No clinical text is returned, and nothing is ordered, billed or signed. They need the same patient-data access as the records below. See Encounters.
  • Network search — finding a listed pharmacy, and checking its availability band, without a direct connection to it yet — see Connections.
  • Connections — an organization requesting access to a clinic by one-time code, and the clinic narrowing or revoking what it granted — see Connections.
  • Workspaces — signing up for a developer portal account, verifying it, and using your sandbox with a test key before anything is live.
  • Looking up which clinic or workspace a key belongs to, and confirming the key itself is valid (GET /v1/me).
  • Your sandbox — invented inventory, pharmacies, patients, notes, appointments and medicine codes, reachable with a test key, with a request you can paste for each on the Sandbox page of the developer portal.

​
What isn’t available yet

If your integration needs any of this, it isn’t ready to build against — check back, or ask us.
  • A self-serve checkout for a workspace’s paid plan. Moving off Sandbox is a request to us today — see Plans and pricing.
  • OAuth, or any authentication method other than a bearer key.

​
Words you’ll see

​
Base URL

Every endpoint lives under this base URL. See Versioning for how the path changes over time.

​
Where to start

Quickstart

Make your first request in a few minutes.

Authentication

How a key is formatted, sent, and kept safe.

Permissions

What a key can be given access to, and how that’s enforced.

API reference

Every endpoint, with its request, response and permission.

SDKs and Postman

Client libraries and a ready-made request collection.

​
Getting a key

  • Building for one clinic you already work with? Ask them to create a key inside their own ClinikEHR workspace, under Settings → API access, and share it with you over a channel you both trust. See the product’s own guide: API access.
  • Building something that reaches more than one clinic? Sign up for a developer portal account — you get a test key and a sandbox immediately. A live key needs your workspace verified, on a paid plan, and to have accepted the API Terms of Use, and it only ever reaches a clinic that has approved a connection to you.