Cliniko vs HealthKit: Getting a Patient's Apple Health Data into Cliniko

Two different things with the same patient in them#

<iframe src="https://aifitnessapi.com/embed/table/compare/cliniko-vs-healthkit/1"
        title="Two different things with the same patient in them — Cliniko vs HealthKit: Getting a Patient's Apple Health Data into Cliniko"
        width="100%" height="500" loading="lazy" style="border:0"></iframe>
<p><a href="https://aifitnessapi.com/compare/cliniko-vs-healthkit">Cliniko vs HealthKit: Getting a Patient's Apple Health Data into Cliniko</a> via AIFitnessAPI</p>

<a href="https://aifitnessapi.com/compare/cliniko-vs-healthkit#tbl-1">Cliniko vs HealthKit: Getting a Patient's Apple Health Data into Cliniko</a> — AIFitnessAPI

So "Cliniko vs HealthKit" is not a choice between two products. A clinic that wants a patient's wearable data needs both: HealthKit is where the data is, and Cliniko is where the clinic wants it to end up.

Does Cliniko integrate with Apple Health?#

Not that we could find, as of November 4, 2026. Cliniko's connected-apps directory lists 96 apps when we re-counted on November 5, 2026, which it says were mostly "developed by third parties", in categories from booking to "Patient care & monitoring". None of their listings mentions Apple Health or HealthKit. A search of Cliniko's help center for "apple health" returns articles on the Apple calendar, Apple Pay and the Apple Pencil, and none on health data.

Some listed apps do move patient measurements into Cliniko. SST Trainer describes heart-rate-based rehabilitation whose clearance letters and insurer reports "are generated from session data and filed to the Cliniko record", and Vively Health a continuous glucose monitoring program where "All patient data syncs to your dashboard". We did not verify whether any of them reads Apple Health; ask the vendor before you assume it.

Why a clinic system cannot read HealthKit directly#

HealthKit has no server to call. Apple documents that with the user's permission "apps communicate with the HealthKit store" on the device, and that "the device encrypts the HealthKit store when the user locks the device", so even an installed app "may not be able to read data from the store when it runs in the background". A web-based practice system like Cliniko has nothing to connect to. Apple adds that on iPadOS 16 and earlier and on macOS 13 and later the devices "don't have a copy of the HealthKit store", so a Mac on the front desk cannot read it either.

Permission is per patient and per type. Apple says "Users can grant or deny permission separately for each type of data", and that "an app isn't aware when the user denies permission to read data". A clinic app has to treat an empty heart-rate history as possibly denied, not as a patient who never wore a watch. Reading the store is covered in the Apple HealthKit integration guide.

The route that works: patient app, your server, Cliniko's API#

1. A patient app on iPhone. It asks for read access to the types the clinic needs, reads them with HealthKit queries while the app can, and uploads them to your backend.
2. Your server matches the patient. Cliniko identifies patients by its own IDs, so your system needs a mapping from your app's user to the Cliniko patient.
3. Your server writes to Cliniko. The documented path for a file is the patient attachment flow: request a presigned upload URL for the patient, POST the file to Cliniko's S3 bucket, then create the attachment record, after which "Cliniko will process the file". A weekly PDF or CSV summary of a patient's activity fits this shape.
4. Practitioners open your view from Cliniko. Cliniko's custom patient buttons add a button to a patient's page that sends the practitioner's browser to your URL with the patient's Cliniko ID, so they can see the charts in your app. Cliniko has to approve the URL first.

What the API docs set out for that server:

• Authentication. HTTP Basic with a Cliniko API key as the username. "Each Cliniko user will have their own API key(s)", and "The API key will have the same permissions as the user it belongs to". Our recommendation is a dedicated Cliniko user for the integration, with only the permissions it needs.
• Identify yourself. Every request needs a User-Agent with your app's name and a contact email; "If your requests do not include a User-Agent that contains a name and valid contact email, future requests may be automatically blocked."
• Limits. "API requests are rate limited to 200 per minute per user", over which you get a 429 with an X-RateLimit-Reset header. Lists are paginated, 50 items by default and up to 100 with per_page.
• Accounts live on shards. The base URL depends on the account; the docs' example is the au1 shard, api.au1.cliniko.com.

Two things we could not verify. The API reference lists a treatment-note resource, but the rendered pages we read did not show which operations it supports, so check whether your integration can write notes or only read them. And we found no webhook resource in the reference's list, so plan to poll with an updated_at filter, which the docs describe, if you need to know when a patient record changes. If the system on the other end is an EHR rather than Cliniko, the standard shape for a wearable reading is a FHIR Observation, covered in wearable data into health records with FHIR.

The rules that come with patient health data#

Apple's rules for your app. Apple's privacy guidance says "You must not disclose any information gained through HealthKit to a third party without express permission from the user", and that even with permission you may share it only with a third party that also provides "a health or fitness service to the user". In our reading a clinic treating the patient is that kind of service, but ask the patient explicitly and say in your privacy policy that data goes to their clinic. Apple also requires a privacy policy for every HealthKit app.

HIPAA, for a US clinic. HHS lists clinics, chiropractors and psychologists among health care providers that are covered entities "only if they transmit any information in an electronic form in connection with a transaction for which HHS has adopted a standard". HHS's business associate guidance names as a business associate an app developer "that contracts with a covered entity to provide the health care app to the covered entity's patients", including for "monitoring of patients' food and exercise". Cliniko says it will set up a Business Associate Agreement on request, and warns in its help center that "some integrators may not be HIPAA-compliant". The wider test is in does a fitness app need to be HIPAA compliant.

GDPR, for a clinic with patients in Europe or the UK. Health data is special category data, and the UK regulator, the ICO, lists data from fitness trackers as health data. Cliniko offers a Data Processing Addendum; your patient app and server need the same treatment. See GDPR for fitness apps.

The API key is the keys to the practice. Cliniko's security page says connected apps "often require your API key in order to link with your Cliniko account" and to share it only with parties you trust. Keep it on your server, never in the patient app.

Which one do you actually need?#

• You run or build for a clinic and want patients' step, heart-rate or workout data in their record → both: a HealthKit-reading iPhone app for the patient, and Cliniko's API on your server.
• You are building a patient app with no clinic system involved → HealthKit only, plus Health Connect if your patients also use Android.
• You want to automate the clinic's own data, such as bookings, invoices or recalls → Cliniko's API only; HealthKit has nothing to do with it.
• You want patients' data from many wearables without writing a phone app per platform → a health-data aggregator can collect it for you, compared in health-data aggregator APIs; you would still write it into Cliniko yourself.
• You want records to flow the other way, from the health system to the patient's phone → HealthKit can read clinical records downloaded from supported institutions, covered in the HealthKit clinical records API.

Sources and limits#

Cliniko's API documentation, features, security and connected-apps pages and its help center were read through a source snapshot on November 4, 2026; Apple's HealthKit documentation was read directly the same day. HHS's pages refuse our fetches, so its guidance was read from Internet Archive captures of October 2026. Cliniko's directory changes as vendors join it, so search it again before you build.