Cliniko
SchedulingConnect AI agents to Cliniko, the practice management system for healthcare clinics. Agents manage patient records, book and reschedule appointments, check practitioner availability, and read invoices, with the regional shard detected from the key itself.
What This Integration Enables
Cliniko is a practice management system for healthcare clinics, and the data behind this connector is patient information. That should shape how a clinic uses it before anything else about it is interesting. This page describes what the connector reads and writes. It does not describe FlowRunner or Cliniko as certifying any regulatory scheme, and it does not change what a clinic is permitted to do with a patient record. Where a workflow moves patient data out of Cliniko, the clinic decides which destinations are appropriate, and that decision is not one an automation should make on the clinic's behalf.
With that established, the surface is a practice's operational spine. Agents read and write patient records, book, reschedule and cancel individual appointments, read practitioner availability directly from the diary, and read invoices. The practice reference data sits alongside it: practitioners, appointment types with their durations and telehealth flags, and businesses, meaning the physical clinic locations. Invoices are read-only in the Cliniko API, which is a useful boundary to know in advance rather than to discover: an agent can pull billing state into reporting, and it cannot issue or amend a charge.
One technical detail is worth stating plainly because it is a genuine concern in health software rather than a configuration footnote. Cliniko runs regional shards, and the connector detects which one to talk to from the suffix of the API key itself. A key ending au1 reaches the Australian shard, uk1 the United Kingdom shard, ca1 the Canadian one. There is no separate region setting to get wrong, and no way for a flow to be pointed at the wrong region by a misconfigured field, because the key carries the answer. For a clinic whose patient data is required to stay in a particular jurisdiction, that is one fewer thing standing between the requirement and the reality.
The rest of the value is ordinary and unglamorous, which is the point. Intake forms become patient records without being retyped. Booking flows read real availability instead of a stale mirror of the diary. Reminder and recall lists come from List Appointments rather than from someone reading the week ahead. Billing state reaches the clinic's reporting from List Invoices instead of a monthly export. None of that touches clinical judgment, and none of it should.
Without FlowRunner
With FlowRunner
Use Case Scenarios
Intake that becomes a booking without being retyped
A prospective patient completes the clinic's intake form, choosing a practitioner and a service. The agent reads the submission, calls List Patients filtered on last name and email, and looks at what comes back. If nothing matches and the identity fields are complete, it calls Create Patient. If exactly one record matches and every field agrees, it calls Update Patient to fold in anything new, such as a changed phone number. If two records match, or the surname matches but the date of birth does not, it writes nothing. In the clean case it then calls Get Next Available Time for the requested practitioner, appointment type and location, and presents the slot with the identity evidence to a practice team member, who confirms before Create Appointment runs. The retyping is gone. The identification is still a person's.
Reminder and recall lists built from the diary, not from memory
Each morning the agent calls List Appointments filtered by start time range for the days ahead, joining each result to its patient through Get Patient and to its service through List Appointment Types. From that it assembles the day's arrivals for the front desk, the list of patients due a reminder, and the patients whose appointment type carries a telehealth URL and therefore needs a link rather than an address. Because the appointment records carry cancellation state, the same read distinguishes a live booking from one that was cancelled overnight, which is the distinction that most often goes wrong when a list is built the night before.
Billing state pulled into reporting without touching the ledger
Invoices are read-only through the API, and that constraint makes this the safest workflow in the connector. On a schedule the agent calls List Invoices filtered by status and issue date, expands the ones it needs through Get Invoice to read items, totals and tax breakdown, and pushes the aggregate into the clinic's approved reporting destination. It can surface which invoices are outstanding, which carry an online payment URL, and how the picture has moved week on week. It cannot issue, amend or void a charge, because the API does not offer it. A practice can adopt this workflow knowing the worst outcome is an inaccurate report rather than an inaccurate bill.
Human-in-Loop Highlight
The gate on this connector sits on Cancel Appointment, and the reason is not that cancelling is technically hard. It is that a cancelled appointment is a person who now has no slot, and this connector has no way to tell them.
Look at what the action list contains and, more importantly, what it does not. Cancel Appointment removes a booking with an optional reason and note, and the cancellation is recorded in Cliniko rather than deleted. There is no messaging action anywhere in the connector, no email send, no SMS. So the appointment disappears from the practitioner's diary and the patient's understanding of their week is unchanged. They arrive on Thursday to a clinic that stopped expecting them on Tuesday. If they were on a waiting list for that slot, or they arranged time off work around it, or they are elderly and travelled, the cost of that silence is not administrative. Rebooking does not automatically undo it either: Get Available Times and Get Next Available Time only look forward and only across a window of at most seven days, so the replacement slot the agent can offer may be a fortnight out and in a different location.
Archive Patient sits in the same category for a quieter reason. Archiving is reversible inside Cliniko, so it is not the permanent deletion it can look like, but the reversal is a person clicking in the Cliniko interface, not an action this connector can call. Meanwhile the archived patient drops out of active lists, which means the recall and reminder workflows built on List Patients stop seeing them. A patient archived by a tidy-up rule is a patient who quietly stops being contacted.
So FlowRunner puts a person at both points. The agent does the work that carries no judgment: it reads the diary, resolves the patient, checks the appointment type and location, and queries the next open slots so the options are ready before anybody is asked anything. Then it stops and raises a human-in-the-loop step for a named practice team member: "The 09:30 Tuesday physiotherapy appointment for Daniel Okafor needs to be cancelled because the practitioner is unavailable. The next open slot with the same practitioner at the same location is 14:00 the following Wednesday. Cancel and offer that slot, cancel and offer a different practitioner on Tuesday, or leave it and I will flag the practitioner instead?" Nothing moves until that answer arrives, and the answer and the person who gave it are recorded against the change.
The division holds across the whole connector. Agents handle administrative work: intake, matching, booking against real availability, list building, billing reads. Clinicians make clinical decisions, and practice staff make the decisions that reach a patient's day. The agent's job is to have every fact assembled at the moment somebody has to choose, and to stop the line rather than guess.
Agent Capabilities
17 actionsPatients
5- List Patients Retrieves a paginated list of patients, optionally filtered by first name, last name or email using partial, case-insensitive matching. Returns up to 100 patients per page with a total count and pagination links. This reads patient information, so route the output only to destinations the clinic has approved for it. This is the matching step in every intake workflow: search before you create, and treat more than one result as a question rather than a tiebreak.
- Get Patient Retrieves the full record of a single patient by ID, including contact details, address, phone numbers, communication preferences and links to related resources such as their appointments and invoices. This reads patient information. Use it once List Patients has established which record is the right one.
- Create Patient Creates a new patient record. Only first name and last name are required, and contact details, date of birth, phone number and address can be supplied alongside them. Further Cliniko patient attributes such as title, sex, time zone and Medicare details can be passed through Additional Fields. This writes patient information, and it is the action that creates a duplicate when the search step was skipped or the result was ambiguous.
- Update Patient Updates an existing patient record, changing only the fields supplied and leaving everything else untouched. One behaviour to know before using it in a bulk flow: supplying a phone number replaces the patient's stored phone numbers with the new one rather than adding to them. Further Cliniko attributes can be passed through Additional Fields. This writes patient information.
- Archive Patient Archives a patient record so it no longer appears in active patient lists. Archiving is reversible inside Cliniko, where a patient can be unarchived from the interface, so this is not a permanent deletion. It is still consequential, because the reversal is not available through this connector and because an archived patient drops out of the lists that reminder and recall workflows read. Belongs behind an approval in any flow that archives on a rule rather than on a request.
Appointments
5- List Appointments Retrieves a paginated list of individual appointments, optionally filtered by patient, practitioner, business location and start time range. Results include booking times, cancellation state and links to the patient, practitioner and appointment type. This is the read behind reminder lists, arrival lists and daily schedules, and the cancellation state is what keeps those lists honest.
- Get Appointment Retrieves a single individual appointment by ID, including start and end times, notes, cancellation details, arrival status, telehealth URL and links to the patient, practitioner, appointment type and business. Use it when a flow needs the telehealth link or the arrival status rather than just the booking window.
- Create Appointment Books a new individual appointment for a patient with a practitioner at a business location. If no end time is given it is calculated from the appointment type's duration, and all times are UTC in ISO 8601 format. Pair it with Get Available Times so the slot being booked is one the diary actually offers, and take the confirmation from a person before it runs in any patient-facing flow.
- Update Appointment Updates an existing individual appointment, which is how a reschedule, a practitioner reassignment or a change of location or service is applied. Only the fields supplied are changed, and times are UTC in ISO 8601 format. Moving an appointment has the same effect on a patient's day as cancelling one, so the same approval applies where the patient has not asked for the change.
- Cancel Appointment Cancels an individual appointment with an optional cancellation reason and note. The appointment stays in Cliniko with its cancellation details attached rather than being deleted, so the record of what happened survives. Nothing in this connector notifies the patient that their appointment is gone, which is exactly why this is the action that belongs behind a person.
Availability
2- Get Available Times Lists the open booking slots for a practitioner, appointment type and business location across a date range. The window between From and To cannot exceed seven days and cannot be in the past. A returned `appointment_start` is what you pass as the Starts At value in Create Appointment, which keeps a booking flow reading from the live diary rather than from an assumption about it.
- Get Next Available Time Returns the single next open slot for a practitioner, appointment type and business location within a date range, subject to the same seven-day, no-past-dates window. Use it where a flow needs one answer to offer rather than a list to choose from, such as presenting a replacement slot alongside a cancellation for a person to approve.
Practice
3- List Practitioners Retrieves a paginated list of the practitioners in the account, with display name, designation, active status and links to their appointment types and appointments. Resolving a practitioner here is the first step in any availability or booking flow, and the active status is what stops a flow offering slots with someone who has left.
- List Appointment Types Retrieves a paginated list of the appointment types configured in the account, including name, category, duration in minutes, colour, telehealth support and online booking visibility. The duration is what Create Appointment uses to calculate an end time, and the telehealth flag is what tells a confirmation flow whether to send a link or an address.
- List Businesses Retrieves a paginated list of the businesses, meaning clinic locations, in the account, including name, address, time zone and online booking visibility. Business IDs are required when booking appointments and checking availability, and the time zone matters because appointment times are handled in UTC.
Invoices
2- List Invoices Retrieves a paginated list of invoices, optionally filtered by patient, status and issue date range, including totals, tax, status and an online payment URL where one exists. Invoices are read-only through the Cliniko API, so this and Get Invoice are the full extent of what an agent can do with billing: report on it, never alter it.
- Get Invoice Retrieves a single invoice by ID, including its line items, totals, tax breakdown, status and links to the related patient, practitioner, appointment and business. Use it where a reporting flow needs the composition of a charge rather than just its total.
Frequently Asked Questions
What can FlowRunner do with Cliniko?
FlowRunner agents can run List Patients, Get Patient, and Create Patient in Cliniko, plus 14 more actions.
Does connecting Cliniko to FlowRunner require OAuth?
No. Cliniko connects to FlowRunner with basic authentication (a username and password), no OAuth flow required.
Can Cliniko trigger a FlowRunner workflow automatically?
Cliniko doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.
Start building with Cliniko
$100 in credits. No card required. Connect in minutes.