Clinic booking system APIs: what can actually be automated.

Two clinics ask for the same thing (a WhatsApp agent that takes an enquiry and puts the appointment in the diary) and get two very different builds. Not because one clinic is more complicated, but because their booking platforms permit different things. The hard constraint on automating a clinic is almost never the AI. It is what the practice-management system lets outside software do.

That question is usually answered too late, after a proposal has been written. So this is the check, done in advance, against each vendor's own documentation.

The four questions that decide everything.

Strip away the marketing and every booking integration comes down to four capabilities:

• Can software read your open slots? Without this, a bot can take a request but cannot tell anyone what is actually available.
• Can it create a booking? The difference between a system that books and a system that only prepares a booking for a human to key in.
• Can it change or cancel one? This is what turns "I need to move Tuesday" from a phone-tag exchange into one reply.
• Are there webhooks? Webhooks mean the platform tells your system the moment something changes. Without them, your system has to keep asking, which works, but it is never quite instant.

Cliniko: the most open of the group, with one real gap.

Cliniko documents a full REST API publicly, and access is genuinely self-serve: any Cliniko user generates a key under My Info, then Manage API keys. There is no partner approval to wait on. The API covers appointments and patients (including creating an individual or group appointment, and a dedicated endpoint for cancelling one) and reads availability through its available-times endpoints. It is rate-limited to 200 requests per minute per user, and it requires a custom user-agent header identifying the integration, which Cliniko's docs warn is not optional.

The gap is webhooks: we could not find them documented anywhere in Cliniko's API reference. In practice that means an integration has to poll on a schedule rather than react instantly. It is a real design constraint rather than a blocker: a reminder that fires on a schedule does not care, but anything that needs to respond the second a diary changes has to be built around the polling interval.

This is the platform behind our Alliance Counselling build, and there is a fuller write-up of what that looks like in practice in our Cliniko and WhatsApp guide.

Zenoti: webhooks and a booking flow, with a rate ceiling to plan around.

Zenoti documents a public API with a two-step booking flow (create the booking, then reserve the slot) plus a Guests API for creating and tracking client profiles from an external app, and a webhooks section covering event responses and failure handling. Access uses an API key generated from a "backend app" created inside Zenoti itself.

The number worth knowing before scoping anything is the rate limit: 60 calls per minute, applied per organisation rather than per user, surfaced through response headers. Higher limits exist but are a paid arrangement through your Zenoti account manager rather than something you can switch on. For a single location that ceiling is generous. For a chain fanning out across many staff and sites, it is a real constraint and should be raised before anyone promises real-time syncing at scale.

Vagaro: capable, but you cannot start on Monday.

Vagaro publishes developer documentation covering both an API and webhooks, with webhook categories for appointments, customers, form responses and transactions, up to ten webhooks per business, and verification-token signing.

The thing to plan around is not capability but access. Credentials are not self-serve: you request them through Settings, then Developers, then APIs & Webhooks, and Vagaro's documentation describes roughly a five business day review before anything is issued. That is a week of lead time before a build can begin, which matters when the whole project is meant to take one to three weeks. If you are on Vagaro, start that request before the scoping call, not after it.

Plato: Singapore-native, with a partner gate for multi-clinic apps.

Plato Medical is the one on this list built for the Singapore market, and it does publish a RESTful API, with live documentation served per-database from its clinic domain. One rule in its developer materials is worth knowing early: a commercial app that integrates with more than one Plato customer must be registered under a developer partner programme. A single clinic commissioning its own integration sits differently from a vendor serving many Plato clinics from one codebase.

We are being straight about the limit of what we checked here: the endpoint reference is served as an interactive documentation app that we could not read as text, so we are not going to characterise exactly which operations it exposes. If you are on Plato, the right move is to get sandbox access from your account before anyone assumes it behaves like Cliniko.

Fresha: ask before you assume.

This is the one most likely to surprise someone mid-project. What Fresha documents publicly is the Data Connector: a paid, read-only, one-way sync of your data out to a warehouse for reporting in tools like Power BI or Tableau. Fresha's own help centre is explicit that Fresha does not receive any data back. There is a login-gated partner portal whose contents we could not see, and a developer subdomain that does not resolve.

So the honest statement is this: we could not find a publicly documented third-party booking API for Fresha. That is not the same as proving none exists behind that login. But it does mean that if you are on Fresha, you should ask Fresha directly what write access is available before anyone scopes a booking automation on the assumption that it is. Any agency that quotes you a Fresha booking integration without answering that question first is guessing with your money.

Calendly: worth watching, not yet worth promising.

Calendly has a long-standing REST API and has announced a Scheduling API intended to let booking happen inside a third-party app without redirects or Calendly-hosted screens, framed by Calendly itself as aimed at AI assistants, automation tools and custom portals. That is a genuinely relevant direction for anyone building conversational booking.

We could only read the announcement, not the endpoint reference, so we are not going to state what it does or does not support for rescheduling, cancellation or webhooks. Verify against a live account before scoping a build on it.

What we could not confirm.

This section exists because an article that only lists what it found is easy to mistake for a complete picture. Several vendors serve their reference documentation as interactive apps that could not be read as plain text, so the following are genuinely unknown to us rather than absent:

• Plato's endpoint list, reschedule and cancel support, patient-record access, webhooks, auth model and rate limits.
• Vagaro's availability reads, booking creation, reschedule and cancel support, and rate limits: the capability sub-pages did not resolve for us.
• Whether Zenoti offers a dedicated availability-read endpoint, its reschedule and cancel support, and its full webhook event list.
• Whether Fresha's login-gated partner portal contains a two-way booking API.
• Calendly's auth specifics, rate limits, webhook events, and whether the Scheduling API is gated to a plan tier.

What to do with this before you commission anything.

Ask your booking platform the four questions above, in writing, and ask for the developer documentation link rather than a sales answer. If the answers are clear, an integration can be scoped with confidence and a one to three week build is realistic. If they are vague, that vagueness is the project risk, and it is far cheaper to find it now than three weeks into a build.

It is also fair to ask the same of whoever is quoting you. An agency that has checked your specific platform before proposing a booking integration will be able to tell you its rate limit, its webhook situation, and how long access takes to obtain. One that cannot has not looked.