The first question almost every clinic asks us is the same: “Will this work with my clinic software?” It’s the right question. An AI assistant that can’t see your diary or write to it can only take messages. To actually book appointments, it has to be connected to the system your team already uses.

The surprise comes later. The technical side of the connection is usually the easy part. What takes time is deciding what the assistant is allowed to do and which data it should see. This guide covers both.

Will it work with my clinic software?

Books directly into PracticeHub and QuiroHiro, and into any diary with an API, such as Cliniko or Google Calendar.

QuiroHiro is our own group’s clinic management software, so the connection with CAi, the AI receptionist from HeyCAi, is direct. With PracticeHub the integration works both ways: what CAi books shows up in PracticeHub straight away, with no manual entry and no duplicates, and whatever you change in PracticeHub, CAi sees instantly.

If you use something else, we’ll go through it on the video call. The first thing we check is whether it has an API.

What an API is, in two lines

An API is the door two programs use to talk to each other automatically. When a patient asks for an appointment on Thursday afternoon, the assistant asks your software’s API which slots are free, offers them to the patient and, once they choose, uses the API again to save the booking.

You don’t need to write any code. You authorise access from your clinic software and we do the rest.

The three types of integration

Not all connections are equal, and picking the wrong one costs time.

Native API integration

The most complete option. The assistant talks directly to your software through its official API: it reads live availability, writes appointments with no middleman and keeps patient details the same on both sides. It’s the one with the fewest day-to-day errors, and the one we use whenever we can, with no middleman tools.

Webhooks

These are alerts. Instead of asking every few minutes whether anything has changed, your software tells the assistant when something happens: a patient cancels, a new record is created, a slot moves. They usually work alongside the API so changes arrive straight away.

Syncing with an external calendar

The lightest option. The assistant only sees a calendar, such as Google Calendar, rather than the whole practice management system: no history, no payments, no patient types. It works for small clinics with a simple diary, but falls short if you want to take real work off your team.

Why syncing has to happen in real time

Picture this. At 10:00 a patient books Tuesday at 17:00 online. Three minutes later another patient rings, and an assistant that only refreshes every so often still sees that slot as free and offers it. Now you have two patients for the same time and an awkward call to make.

With real-time sync that doesn’t happen. When the second patient rings, the assistant checks the diary at that moment, sees Tuesday at 17:00 is taken and offers the next free slot. If a patient books online, that slot is blocked for CAi instantly, and the other way round.

What needs to stay in sync:

  • Free and booked slots for each practitioner.
  • Patient details, so existing patients are recognised and no duplicate records are created.
  • New appointments, changes and cancellations.
  • Diary blocks: holidays, training days, breaks.

What the assistant sees and what it doesn’t

A good integration syncs only what’s needed. More data doesn’t make an integration better: it makes it more fragile and gives you more GDPR work.

With PracticeHub, CAi reads the calendar and availability, basic patient details (name, phone and email) and appointment types and lengths. It doesn’t read clinical notes or medical records.

Permissions are kept to a minimum: read the diary and create or change appointments. It doesn’t need admin rights to your software, and you can revoke access from your own system whenever you like.

The reason for keeping clinical records out isn’t technical. Health data is a special category under GDPR, and the less the assistant sees, the lower the risk and the less there is to review. For the legal detail, see our GDPR guide for clinics and our security page.

What really takes time: the decisions

Before switching anything on, there are a few questions nobody thinks about at the start:

  • Which appointment types can the assistant create without anyone checking?
  • Does it hold the slot while it’s talking to the patient, or only once the booking is closed?
  • What happens if the patient switches practitioner halfway through the conversation?
  • Who takes the call when the assistant doesn’t know what to do?

Each answer involves your clinical team, reception and sometimes whoever looks after data protection at your clinic. Clinics that arrive with these thought through get going sooner.

Common mistakes and how to avoid them

Two bosses for one diary. This happens when the assistant and reception both change appointments with no clear rule. Decide from day one which system has the final say, which is usually your clinic software.

Syncing late. If the assistant checks the diary every few minutes instead of receiving changes as they happen, last-minute bookings clash.

Nobody to hand over to. The assistant needs to be able to pass a case to a person rather than make up an answer. With CAi, if something falls outside what it knows, it puts the call through to you or an on-call number, or takes a message and alerts your team on WhatsApp. You choose.

Not testing with real calls. Demos are tidy. Real life brings patients who change their minds, background noise and local ways of speaking. A week of testing with real calls before opening it up to everyone catches almost everything.

What to have ready before you start

  1. Which clinic software you use, and which version.
  2. What you want to automate first: bookings, reminders, cancellations.
  3. Who decides when the assistant doesn’t know: the on-call practitioner, reception, or nobody until the next day.
  4. Which data can leave your software and which can’t.
  5. Who at the clinic will own the project.

With that in hand, getting started is much easier. Up and running in about 20 days: two weeks of configuration, one week of testing and one week of gradual rollout. We’re with you through the whole process.

If your software has no API

Some older systems don’t have a public API. That doesn’t make them bad, but it does mean they can’t be connected directly. You have three ways out, all with limits:

  • Use an in-between calendar, such as Google Calendar, if your software can sync with it.
  • Ask your supplier to open up an API. More and more do, because their customers ask for it.
  • Move to software that has one.

Which one suits you, we’ll go through on the video call.

Several sites or several systems

If your group has several sites, each one can use different software and CAi handles each integration separately, with its own number and diary.

If one clinic uses two systems (one for the diary and another for payments, say), that can work, but you need to decide which one wins when both change the same appointment.

Frequently asked questions

Which clinic software does it work with?

Books directly into PracticeHub and QuiroHiro, and into any diary with an API, such as Cliniko or Google Calendar. If you use something else, we’ll go through it on the video call: the first step is checking whether it has an API that lets us read the diary and save appointments.

Do I need to code or give it admin access?

No. You authorise access from your clinic software and CAi only asks for the permissions it needs: reading the diary and creating or changing appointments. It doesn’t need admin rights, and you can revoke access from your software whenever you like.

What happens if my supplier changes its API?

We keep the integration up to date when the supplier changes its API. We also monitor the sync and let you know if it disconnects.

What if I disconnect the integration?

CAi stops syncing. Appointments already booked stay in your software, and you can reconnect later without losing data.

How do I handle holidays and closures?

Mark that block as “Unavailable” in your diary or just tell CAi, for example: “Don’t book anything from 15 to 22 August.” It won’t offer slots on those dates.

How long until it’s working?

Up and running in about 20 days: two weeks of configuration, one week of testing and one week of gradual rollout. You can hear what it sounds like first in the demo.