Cliniko integration: native features, Zapier, Make or the API

Start with Cliniko itself. It has native integrations with Xero and Mailchimp, a directory of connected apps built by other companies, online bookings that create or match patient records, patient forms that attach to the record, and automatic reminders and follow-up messages. If one of those does the job, use it: someone else maintains it, and it already knows Cliniko's data.

When none of them fits, there are three routes. Make lists a Cliniko app with triggers for new patients, new appointments, ended appointments and new invoices, plus actions to create and update patients and appointments. Zapier, as far as we could find in October 2026, has no Cliniko app, so a Zap reaches Cliniko through webhooks and HTTP requests to its API. And you can write your own code against the Cliniko API, which is a REST API that returns JSON.

Our position: integrate only for the gaps, and keep the integration narrow. The three gaps we see most are a form on the clinic's own website that should create the patient before the first visit, bookings that should reach a CRM or marketing tool, and recalls or reminders that need logging Cliniko does not do. Where this breaks: any integration that moves patient data copies health information into another system, and that is a decision the practice owns, not the integrator.

The API reaches most of what staff see in Cliniko. This table covers the parts an integration usually touches, as Cliniko's API documentation describes them in October 2026. Check the current reference before you build, because endpoints are added and deprecated.

Five rules apply to every call, whether it comes from Make, Zapier or your own code:

• Authentication is HTTP Basic, with the API key as the username and an empty password. Cliniko says to handle the key like a password, because it opens sensitive information.
• Keys belong to users. Each Cliniko user has their own API keys, and a key has the same permissions as its user. A user has to allow API keys on their own profile before they can create one, the key is shown once, and archiving it cuts off whatever was using it. Create a dedicated user for the integration with only the access it needs, so the integration does not stop when a staff member leaves and does not see more than it should. Check Cliniko's pricing page for whether an extra user affects your plan.
• The key's suffix is the shard. The characters after the hyphen at the end of the key (au1, uk1 and so on) say which shard the account lives on, and requests go to https://api.{shard}.cliniko.com/v1. Cliniko lists shards in Australia, Canada, the UK and the EU, and says keys created before sharding have no suffix and belong to au1. A UK clinic calling the au1 address will fail authentication.
• Every request needs a User-Agent header naming your application and a contact email, in the form 'App name (email)'. Cliniko says it uses this to contact you about problems, and that requests without a compliant header risk being blocked. Send Accept: application/json as well.
• The limit is 200 requests a minute per user. Above it, Cliniko returns a 429 response with an X-RateLimit-Reset header giving the reset time. A form that creates a few patients a day never comes close. A backfill does: as an illustration, 5,000 patients that each need one search and one create is 10,000 requests, which takes at least 50 minutes at 200 a minute, so pace it and handle the 429.

One more thing we looked for and did not find: webhooks. We found no way in Cliniko's API documentation to have Cliniko push an event to you when a patient or appointment changes. Treat that as a finding to check, not a fact. In practice it means anything that reacts to Cliniko, including Make's watch triggers, works by checking on a schedule, so it runs minutes behind and each check costs a credit or a request whether or not anything changed.

Most Cliniko automation requests we would answer with a setting. Before paying for a build, check these:

• Online bookings. Patients book without a login. The booking page collects basic details and matches them to an existing record, or creates a new one. One catch, from Cliniko's own help: a patient whose record is archived gets a new record when they book online, and the two then need merging.
• Patient forms. Cliniko's own forms can go out with the confirmation email, set up so that only new-patient appointment types send the intake form, and submitted forms attach to the patient's record. They are sent to each patient individually: each link works once, expires after a week if unused, and cannot be embedded on a website.
• Reminders and follow-ups. Reminders go by email, SMS or both, for the appointment types that have a reminder template linked, and respect the patient's own reminder preference. Confirmations are email only. Follow-up messages can be sent automatically anywhere from a day to two years after an appointment. SMS needs credits.
• Recalls. Cliniko has recalls, which work as reminders for staff to contact a patient and show up in reports. Check the current help centre for what they automate, because several connected apps exist to add automated recall messages on top.
• Xero and Mailchimp. Both are native integrations, covered below, each with limits you should know before switching it on.
• Connected apps. Cliniko's directory lists third-party products that already integrate, for intake forms, recalls, reviews and more. One of them may be cheaper than a build, but it is another vendor holding patient data, so the same questions apply to it as to us.

The forms point matters most for intake. Because Cliniko's own forms cannot be embedded on a website and are sent per patient, a clinic that wants a public 'new patient' or enquiry form on its own site has to collect it somewhere else and get it into Cliniko. That is the job we were hired for.

Between Make and Zapier, choose by where the rest of the clinic's automation already lives and who will open it when it fails. Make's Cliniko app saves you writing requests, and its routers suit flows with several branches. Zapier suits a straight line from a form plugin that already has a Zapier add-on. Our Make vs Zapier vs n8n comparison covers billing and control flow in general.

This is the integration we are asked for most, and the one with our own evidence behind it. A clinic in New South Wales, Australia, had an existing Gravity Forms form on its WordPress site. The brief was for that form to create a patient record in Cliniko through Zapier webhooks, with the form's fields mapped to Cliniko's patient fields. It was a short hourly engagement of about ten hours, and the client left this review:

We have also built Gravity Forms into Cliniko on Zapier with conditional logic, where different answers on the form lead to different settings in Cliniko. That is not a published case study, so we give no figures or results for it. What follows is the design we would recommend now, on any platform.

1. 01Send only the submissions that should become patients. Gravity Forms' Zapier Add-On and its Webhooks Add-On both let a feed run only when conditions on the form are met, so a general enquiry does not create a patient. Put that rule in the feed, where it is visible, rather than in a filter three steps later.
2. 02Normalise before you search: trim names, put the date of birth in the YYYY-MM-DD format the API uses, lower-case the email and put phone numbers in one format. Most duplicates start as a formatting difference.
3. 03Search Cliniko for a patient with the same email and the same date of birth. Email alone is not enough: parents book for children and couples share an address, so one email can belong to several patients. Cliniko's own advice when merging is to check date of birth and mobile number, because names are not unique.
4. 04Decide on the result. No match: create the patient. Exactly one match: do not create, and do not overwrite. At most, fill fields that are empty on the existing record, and only contact fields such as a missing mobile number. More than one match, or an email match with a different date of birth: stop and send it to a person.
5. 05Apply the conditional settings explicitly. If answers on the form decide which business, practitioner or appointment type applies, keep that mapping in one table or one router, not scattered across steps, so the clinic can read it.
6. 06Write back what happened: the Cliniko patient ID, or 'sent for review', against the form entry, so a re-run or a duplicate submission is recognised and nothing is created twice.
7. 07Alert a named person on failure, with the form entry's ID in the message and no health details in it.

The rule about never overwriting matters more than it looks. A patient who fills in a website form with a new surname, an old address or a typo should not silently change the record a practitioner relies on. Contact details can be confirmed at the desk. A wrong merge is worse: Cliniko says merging cannot be undone.

Where this design breaks: if the form asks clinical questions, such as medical history, medications or the reason for the visit, those answers pass through Gravity Forms, the automation platform and its run history before they reach Cliniko. Gravity Forms saves entries in the WordPress database and keeps them indefinitely unless the form's retention setting says otherwise. For clinical questions, Cliniko's own patient forms are the better place: let the website form create the patient and book the visit, and let Cliniko send the intake form with the confirmation email.

The second common request is the reverse: when a patient is created or an appointment is booked or ends, put them in the clinic's CRM or email tool, to follow up enquiries that never booked or to send a newsletter. Make's Cliniko app has watch triggers for new patients, new appointments and ended appointments, which is most of what this needs. On Zapier it means a scheduled request to the API and your own record of what you have already processed.

Send the minimum. A marketing tool needs a name, an email address, a consent flag and perhaps a last-visit date. It does not need a date of birth, a practitioner or an appointment type. In our view the appointment type is the field people forget: a type called after a condition or a body part tells a mailing list why the patient came, and that is health information.

If you use Cliniko's native Mailchimp integration, know three things from Cliniko's help centre. It sends fields including date of birth, the latest practitioner seen and the latest business visited. It sends every patient with an email address, and the patient's marketing preferences in Cliniko do not affect whether they are added. And archiving a patient unsubscribes them in Mailchimp, but deleting a patient does not remove the Mailchimp record, which has to be removed separately. Whether that is acceptable for your list is a question for the practice and its privacy adviser. If it is not, a filtered integration that checks a consent field first is a reason to build.

Cliniko sends appointment reminders and follow-up messages itself, so build reminders only when they have to go through another channel or follow rules Cliniko does not have. Recalls are the stronger case: deciding who is due, messaging them, and then seeing who replied or booked is a loop Cliniko's staff-facing recalls do not close on their own.

Our published example is a set of Make flows for a multi-site medical clinic. That write-up does not name the clinic's systems, and we make no claim that either of them is Cliniko. The patterns carry over. Across five flows and 12 scenarios, six switched on and six built but off, Make's counters show 446 runs and 74,418 operations. The recall loop keeps the rule for who is due as a formula in Airtable, sends at most 100 patients a run, logs every message and stamps the patient so nobody is messaged twice, and a webhook records who replied or booked. Its live recall has 30 runs and 180 operations with no errors. The appointment reminders send at midday and run a catch-up pass at six that skips anyone already in the log, with 74 runs and 4,503 operations across the two.

The write-up is also clear about the gap that matters here: none of those scenarios checks consent or opt-out itself. For a Cliniko clinic we would read the patient's reminder and marketing preferences before every send, and keep the log of what was sent to whom, because the log is what you will be asked for if a patient complains.

Use Cliniko's own Xero integration. It pushes invoices to Xero as soon as they are created in Cliniko, and payments once they are allocated to invoices. You choose default Xero accounts for invoice items and payments first, and it does not work until you do. It also has limits worth knowing before your accountant meets them:

• Credit allocations in Cliniko do not appear in Xero, and an invoice paid with account credit stays open in Xero until someone records the payment by hand.
• One Cliniko payment spread across several invoices arrives in Xero as several payments. Cliniko suggests Xero's Find & Match to reconcile them to one bank line.
• Sending older records is a background job, records arrive in no particular order, and payments are slow, because, as Cliniko explains it, Xero accepts one payment a minute from the integration. Already-synced records are not duplicated.
• If the connection drops, you reconnect and synchronise the invoices missed in the meantime. Cliniko also says Xero no longer supports invoicing integrations with Cashbook and Ledger organisations.

We found no Cliniko API endpoint for creating invoices, so an automation cannot easily replace this integration in any case. Build around it only when the books need something it cannot do, such as invoices from several Cliniko businesses posting to different Xero organisations, and then read invoices from Cliniko rather than recreating billing elsewhere. Our WooCommerce Xero integration article covers line items, tax, contacts and duplicate invoices in Xero itself.

This is not legal advice, and the practice, not its integrator, decides what its obligations are. What we can say is what the regulators publish. In Australia, the OAIC treats health information as sensitive information, and its guidance on Australian Privacy Principle 7 says sensitive information may be used for direct marketing only with the person's consent, even where they are already a patient. In the UK, the ICO treats health data as special category data under UK GDPR, which needs both a lawful basis under Article 6 and a condition under Article 9. Electronic marketing has its own rules in both countries, and other countries have theirs. Cliniko publishes help articles on how it supports the Australian Privacy Principles and UK GDPR, which are a good start; your privacy adviser is the next step.

The rules we build to, whatever the jurisdiction:

• Never move clinical content out of Cliniko into marketing, CRM or messaging tools: treatment notes, form answers, attachments, diagnoses, or appointment types that reveal them.
• Send each tool only the fields its job needs, and write the list down. If a field is not on the list, it does not go.
• Check consent and preferences in the flow, before the send, not by assuming the list was clean.
• Use a dedicated Cliniko user for the integration with the least access that works, so the key cannot read clinical records it does not need.
• Keep keys out of plain view. Zapier says Webhooks by Zapier stores credentials in plaintext step fields that anyone with access to the Zap can read, and recommends API by Zapier, which keeps them in a connection. On Make, use a connection rather than a typed header where you can.
• Remember the copies. Form entries sit in WordPress, and automation platforms keep a run history of the data that passed through. Set a retention period on the form, and check who can see the platform's history and for how long.
• Log what was sent, to whom and when, without logging the health details themselves.

Our case study on a privacy-first consumer health app takes the same view at the database level: each category a user shares with a partner is its own consent, enforced in the database rather than the app. An integration should treat Cliniko data the same way.

Most of these fail quietly: the form still says 'thank you' while nothing reached Cliniko. Send every failure to someone who will look, and once a week compare the number of form entries with the number of patients created. Our article on why automations break covers the general pattern.

Skofi is paid to build integrations on Zapier, Make and APIs, so we gain when you build rather than switch on a setting. Our advice is still to use Cliniko's native features where they fit. Our evidence is the Gravity Forms to Cliniko build for a clinic in New South Wales, a further Gravity Forms to Cliniko build with conditional logic that is not a published case study, and the Make write-up for a multi-site clinic, which is published with its limits stated. We are not a Cliniko, Zapier, Make, Gravity Forms or Xero partner.

Before any build, write two lists. The first: what should happen, in Cliniko, for a new patient, a returning patient, a parent booking for a child and someone who only has a question. The second: every field that will leave Cliniko, where it goes and why. If Cliniko's own settings cover the first list, you are done. If not, the second list is the scope of the build, and it is usually shorter than people expect.