AI Receptionist for Cliniko: Integration Guide

An AI receptionist connected to Cliniko should do more than send a booking link. To complete an appointment reliably, it must respect the practice's businesses, practitioners, appointment types, availability rules, patient records and conflict handling.

This guide explains the operational contract to test. It does not mean every AI receptionist supports every action, and a connector should not be treated as generally available until it has been validated against the practice's real account and configuration.

For the overall service-model decision, first compare a virtual AI receptionist with a human answering service.

What Cliniko exposes

Cliniko describes itself as a practice-management system for healthcare practitioners and publishes an official REST API. Its API includes resources for businesses, practitioners, appointment types, available times, patients and individual appointments.

The official Cliniko API reference documents operations to read available times and create, update, cancel and inspect conflicts for individual appointments.

That provides the components of an integration. It does not by itself make a receptionist workflow safe. The connector still has to map a conversation to the correct records and handle partial failure.

The minimum booking workflow

1. Select the correct business

A multi-location practice needs an explicit location selection or a dependable routing rule. Do not offer availability from one business and write the appointment to another.

2. Resolve the service

The caller's description must map to a valid Cliniko appointment type. The integration should not guess when two services have similar names but different duration, eligibility or price.

3. Resolve the practitioner

The caller may request a named practitioner, any eligible practitioner or a specific discipline. The workflow needs a clear mapping between the receptionist's provider vocabulary and Cliniko practitioner identifiers.

4. Read eligible availability

Cliniko's API documentation says available-time results respect online-booking settings, including enabled businesses, appointment types and practitioners. A workflow should use the intended source of availability and explain when no eligible slots are returned.

5. Match or create the patient

Patient matching is safety-critical. A name alone is not a dependable unique identifier. The practice should define which fields are used, what happens when multiple matches exist and when staff must review rather than create another record.

6. Create the appointment

The receptionist should only say “confirmed” after the create operation succeeds and the integration records the Cliniko appointment identifier.

7. Check conflicts and recover

A slot can be taken between the availability read and booking attempt. The connector should detect the conflict, avoid a duplicate and offer another option or create a staff task.

Rescheduling and cancellation

Changing an existing booking requires additional controls:

• Verify the caller using the practice's approved process
• Locate the correct appointment
• Preserve the existing appointment until the new action succeeds
• Apply notice and cancellation policies
• Record the reason where required
• Confirm the final state back to the caller
• Escalate ambiguous matches

A natural conversation is not proof that the underlying record was updated.

API-key and data security

Cliniko's official API introduction says API keys allow access to sensitive information and should be handled like passwords. It also documents HTTPS, per-user API keys and region-specific API hosts.

For a deployment, verify:

• The API key belongs to a dedicated integration user where appropriate
• Permissions are limited to the required workflow
• The secret is encrypted and not exposed to the browser or model prompt
• Logs redact credentials and unnecessary patient data
• Region routing follows the account's Cliniko API host
• Key rotation and revocation are documented
• Access and write actions are auditable

Questions to test in a live validation

1. Which business, practitioner and appointment-type combinations are supported?
2. Does the agent read the same availability staff see for this workflow?
3. Can it distinguish no availability from an API failure?
4. How are existing patients matched?
5. What prevents duplicate patient and appointment records?
6. What happens if a slot is taken during the conversation?
7. Can the integration reschedule and cancel, or only create?
8. How are time zones handled?
9. What will the caller hear when a write fails?
10. Can staff inspect and correct every automated action?

A safe rollout sequence

Start read-only: use the connection to find availability while staff confirms the booking. Then allow a narrow group of appointment types, practitioners or locations to accept automated writes. Review every created appointment before expanding.

The AI receptionist implementation checklist includes failure tests and acceptance metrics. Medical and wellness practices should also use the patient-facing workflow guide to define clinical and privacy boundaries.

Vantra and Cliniko

Vantra's Cliniko adapter is in private validation, not presented as an unrestricted general-availability integration. The intended workflow covers configured availability and appointment actions, with deployment-specific mapping and failure handling. Suitability must be confirmed against the practice's real Cliniko configuration.

If that matches your use case, contact Vantra with the locations, appointment types and actions you want to validate. Vantra Concierge defines the communication and handoff layer around that connection.

Final takeaway

The value of an AI receptionist and Cliniko integration is not the API connection itself. It is a dependable chain from caller intent to the correct business, practitioner, patient and appointment-with truthful confirmation and a safe fallback when any step fails.