Cliniko API integrations: practitioner's guide for AU clinics

Quick answer: Cliniko ships with one of the cleanest, most consistently documented REST APIs we work against in Australian allied health. The core entities — patients, appointments, practitioners, appointment types, businesses, treatment notes, signatures — are all exposed, sensibly paginated and easy to build against. The gaps are real and worth knowing about up front: there’s no native room or resource entity, no native membership or class-pack concept, and Cliniko does not push webhooks. Most custom builds we do on Cliniko sit in the gaps between these realities and what the practice actually needs from a customer-facing booking experience, a multi-platform sync, or operational reporting.

Cliniko is the dominant practice management system across Australian allied health — physiotherapy, osteopathy, chiropractic, podiatry, occupational therapy, psychology, and increasingly multi-modality practices that bundle treatment, recovery and wellness services into one operation. The platform is fast, well-priced, and the API is documented openly at docs.api.cliniko.com. For most clinics, the question isn’t whether to use Cliniko. It’s how to wire it more cleanly into the customer-facing layer (the website, the booking widget, the patient app), into the back-of-house layer (accounting, CRM, marketing automation), and into the operational layer (reporting, capacity-aware marketing decisions).

Four patterns cover most of the integration work allied-health practices come to us about.

What Cliniko’s API actually gives you

Cliniko’s REST API exposes the entities you’d expect for a practice management product: businesses (one Cliniko account can run several physical locations), practitioners, patients, appointments, appointment types, services, treatment notes, signatures, patient forms, patient form templates, and patient attachments. Authentication is HTTP Basic with per-user API keys, requests go to a per-account “shard” URL (api.au1.cliniko.com, api.au2.cliniko.com and so on), responses paginate with total_entries and next cursors, and filters use a q[] syntax that is straightforward to work with.

In our experience, the API is one of the cleaner ones in the AU allied-health space — consistent shapes, predictable pagination, well-documented edge cases. The OpenAPI spec is available, and Cliniko’s support team responds to integration questions reasonably.

What that means practically: if you can describe an integration in terms of patients, appointments, practitioners and treatment notes, you can build it. The patterns below are the ones we see most often.

Pattern 1: Branded customer-facing booking widget

Cliniko ships with a hosted booking page. It works. It’s also not on your domain, it’s not branded to your clinic, and it doesn’t let you capture custom intake fields, signatures, waivers, or marketing-segmentation data at the point of booking. For clinics where the booking flow is the first impression a new patient gets, this is enough of a problem to want a custom layer.

The pattern we build most often is a booking widget embedded directly in the clinic’s website. The flow walks the customer through the same five steps Cliniko’s own widget uses (service category → specific service → date and time → details and waiver → confirm), but rendered in the clinic’s brand, on the clinic’s domain, with whatever custom intake fields the practice wants to capture before the booking lands in Cliniko.

The Cliniko entities that drive this are appointment types, businesses, practitioners, available times (real-time slot availability), and patients. The patient form, signature and patient attachment endpoints handle the intake / waiver capture — signatures store as Base64 PNG attached to the patient record, waiver documents store as PDFs against the patient record, and intake-form responses store as structured patient-form data.

One gap to flag honestly: Cliniko does not have a separate room or resource entity. If a clinic has self-service equipment that needs to be bookable in its own right (a hydro pod, an EMS device, a float pool), the typical workaround is to model each piece of equipment as a Practitioner. This works — the appointment-type / available-time / appointment flow all behave correctly — but it’s a workaround, not a native pattern, and worth knowing about up front.

Pattern 2: CRM and marketing automation handover

Cliniko is excellent at being a practice management platform. It is not a marketing platform. For clinics doing meaningful patient acquisition, retention or campaign work, the pattern is to dual-write every booking and customer record into a CRM or marketing automation tool — GoHighLevel, HubSpot, ActiveCampaign and Mailchimp are the four we see most.

The typical dual-write flow: a new booking lands in Cliniko via the booking widget (or admin entry), and a parallel write fires to the CRM with the customer’s contact details, the service they booked, and a tag identifying the booking source. The CRM then handles the marketing layer — appointment confirmations beyond Cliniko’s native ones, follow-up sequences, win-back campaigns, review-request automations, segmentation based on which service was booked.

Here’s the practical reality worth being upfront about: Cliniko does not emit webhooks. The Cliniko side of any sync needs to be the authoritative write — meaning the integration writes to Cliniko first, then writes to the CRM second, with retry logic on the CRM side if the second write fails for any transient reason. Polling the Cliniko API for changes is technically possible, but the rate-limit and operational cost make it inefficient for anything beyond admin-entered bookings that didn’t flow through your custom widget. We treat website-side bookings as authoritative and admin-side bookings as best-effort, which has been a reasonable compromise.

Pattern 3: Accounting reconciliation

Cliniko handles patient billing well. It doesn’t handle clinic accounting at the depth most practice owners need. The standard pattern is to push invoice and payment data from Cliniko into Xero or MYOB so the clinic’s accountant has a complete picture without manual data entry.

The Cliniko API exposes invoices, payments and patient billing data cleanly. The integration writes per-transaction journal entries (or a daily summary) into Xero or MYOB, handles GST treatment correctly, and reconciles against the clinic’s bank feed.

In our experience, this is the highest-ROI Cliniko integration for established practices. The cost saving on bookkeeping time alone usually justifies the build, and the operational benefit of being able to see profitability per practitioner / per service / per location is the kind of insight that influences pricing and staffing decisions.

Pattern 4: Capacity-aware operational reporting and ad-spend optimisation

The most strategic integration pattern we build — and the one most directly relevant to multi-modality clinics — is reading Cliniko’s live appointment-slot availability data and feeding it into operational dashboards or marketing automation decisions.

The Cliniko available_times endpoint exposes free / busy windows per practitioner per service per business in real time. Pulled hourly into a normalised capacity model, this data can drive: an operations dashboard the principal practitioner can read on a phone (utilisation per practitioner, per service, per location); marketing automation that pauses ad spend when the team is booked solid for the next 14 days and scales spend back up when a cancellation cluster opens new capacity; and reporting that surfaces structural issues (a service category that’s persistently over- or under-booked, a practitioner whose mix needs rebalancing) before the practice owner has to chase them down manually.

This is one of the patterns that drives our own IntelliClinic platform — the live capacity data Cliniko exposes is exactly what closes the loop between “we are paying Google for clicks” and “we have practitioners with open hours to fulfil those bookings.”

A key boundary to be deliberate about: this integration reads free / busy data only. It does not need to read patient records, treatment notes, or any other PII to do its job. The architecture should respect that boundary explicitly, especially for AHPRA-regulated practices.

Where Cliniko stops being the right answer

Cliniko is excellent at what it does. There are a few specific cases where, in our experience, an integration alone isn’t enough and a different conversation is worth having:

• Complex membership packs with credit tracking. Cliniko does not have a native concept like “buy 10 sauna sessions for $400, debit one credit per visit, refund the unused credits on cancellation.” Concession Types handle discounted pricing well; the credit-pack pattern needs a custom layer (or a separate platform) that holds the pack state and writes individual sessions back to Cliniko.
• Class-based group fitness operations. Cliniko handles group appointments, but the experience is built around clinical group-treatment scenarios, not high-volume group fitness with class waitlists, drop-in pricing and class-pack memberships. For class-led businesses, a class-led platform like Hapana is usually a better starting point.
• Multi-modality businesses with a strong retail-product component. If a meaningful share of clinic revenue is retail product (supplements, equipment, branded merchandise), the e-commerce surface is often better built on a dedicated platform that pushes orders into Cliniko or accounting separately.

For everything that does fit Cliniko’s shape — clinical appointments, treatment notes, allied-health billing, multi-practitioner scheduling across one or several physical locations — the API gives you everything you need to build the missing layers.

How we usually approach a Cliniko integration project

The work tends to fall into three sequential pieces:

1. Audit the practice and its actual workflow. What the team does today on paper, in Cliniko, in spreadsheets, and across the staff WhatsApp group. The integration only earns its place if it removes the right friction.
2. Build the missing layer. Whichever of the four patterns above (or some combination) the audit points at. Cliniko stays the source of truth; the integration sits on top.
3. Validate against the live Cliniko account before cutover. Cliniko configuration realities — how services are named, how appointment types map to fees, whether equipment is set up as practitioners, whether locations are configured as separate businesses or as one — vary clinic to clinic. Every integration we build needs to be sanity-checked against the live data shape before it goes anywhere near a real patient booking.

If you’re running a Cliniko-based clinic and weighing custom work, we’re happy to walk through your situation specifically. The patterns above cover the majority of what we see, but every clinic has its own shape, and the answer to “what should we build” usually starts with “here’s what your week actually looks like.”