Use case
AI appointment booking, sorted by what each system's API actually permits
AI appointment booking means a caller describes what they want, the agent checks live availability in your real calendar, and the appointment is written before the call ends. Whether that last step is possible depends entirely on the software you already run: of nineteen booking and scheduling systems we have checked against their own published API references, eleven expose an endpoint that creates an appointment, one exposes no create endpoint at all, and four are gated behind partner approval. The table below names the endpoint in each case.
Every row is read from the vendor's own endpoint index or OpenAPI specification, not from its marketing pages. What a vendor's API permits is the ceiling; how far a particular build goes is a scope decision made with you before anything is written.
Which booking systems can an AI receptionist actually write to?
Nineteen checked against their own published references. The classification is about what the API permits, and where a system cannot be written to we say so on its page rather than describing the gap as a feature.
| System | Can an appointment be created? | Evidence |
|---|---|---|
| Open Dental | Yes | Appointment endpoints, including the ASAP short-call list |
| Square Appointments | Yes | Bookings API; calendar and card terminal are one account |
| ServiceTitan | Yes | Jobs and booking endpoints |
| Mindbody | Yes | POST appointment/addappointment, waitlist supported |
| Clio | Yes | POST /calendar_entries.json, from the published OpenAPI spec |
| GoHighLevel | Yes | POST /calendars/events/appointments |
| Google Calendar | Yes | Events: insert, with Freebusy: query for availability |
| Microsoft Outlook | Yes | Graph Create Event, with getSchedule and findMeetingTimes |
| Calendly | Yes | POST /invitees, books end-to-end since the Scheduling API |
| Housecall Pro | Yes | Create a Job, plus the Leads channel |
| Acuity Scheduling | Yes | Appointment creation; no documented read endpoint |
| Jobber | Behind login | GraphQL API; booking mutations are not publicly documented |
| Boulevard | Partner-gated | cart.reserve holds a slot mid-call, Enterprise tier only |
| Jane | Partner-gated | Approved partners only, practitioner-level OAuth2 consent |
| Fresha | Partner-gated | No public API reference published at all |
| Vagaro | No, reads only | No create endpoint in the published index. We send a booking link instead |
| Stripe | Not a calendar | Deposits and payment, where booking and payment are separate systems |
| Slack | Not a calendar | Where the handoff lands when a call needs a person |
| Zapier | Not a calendar | Long-tail connections, never in the path of something a caller waits on |
Vagaro is the row worth reading closely, because it is the one that cost us something. An earlier version of our own research recorded it as booking appointments, taken from a search summary rather than the endpoint index. It has no create endpoint. We publish the correction because a capability claim a prospect can disprove in one API call is worth less than nothing, and because the honest answer, a booking link sent during the call, works.
What has to be true for a phone booking to actually stick?
Three things, in order, and a system that manages the first two but not the third produces a confident-sounding call and no appointment.
First, live availability has to be readable during the call. Not a cached copy synced overnight: the actual state of the calendar at the moment the agent is offering a time. This is where a surprising number of integrations stop: several systems will happily accept a written appointment but expose no way to ask what is free, which means an agent either books blind or does not book at all.
Second, the agent has to hold your rules about what may be booked into what. Appointment length by service, buffers, which practitioner can do which treatment, how far ahead a first-time client may book, which slots are held for emergencies. None of that lives in the API; it lives in your business, and it is what the build session is for.
Third, the write has to succeed and the caller has to be told. A booking that fails silently after the call has ended is the worst outcome available, worse than never offering the slot, because the customer is now expecting to be seen. Confirmations go out by text after the call, which is also what gives the caller something to check against.
Where a system cannot be written to, the honest arrangement is a booking link sent by text during the call, with the agent staying on the line long enough to confirm it arrived. That is a weaker outcome than a completed booking and we describe it as one, but it is a great deal stronger than a message in a voicemail box.
What kinds of appointment does this actually suit?
Appointment booking by phone works best where the calendar is the product and the caller knows roughly what they want. It works least well where the first conversation is a diagnosis.
- Strong: repeat and routine bookingsA hygiene appointment, a six-week trim, a maintenance visit. The service is known, the duration is known, and the only open question is when.
- Strong: first appointments with a fixed shapeConsultations, assessments, intakes. The slot length is standard even when the outcome is not, which is exactly what a calendar needs.
- Weaker: work that has to be seen to be scopedMost trades. The right outcome is usually a site visit booked against a stated call-out fee rather than a job booked against a guessed duration, which is a booking, just not the one the caller asked for.
- Deliberately out of scope: anything clinicalThe line schedules; it does not triage. Where urgency changes what should be booked, that is an escalation rule you define rather than a judgment the agent makes.
Any AI receptionist can say the words you are booked in for Thursday. AnswerAI tells you before you sign which endpoint in your own booking system makes that true, and exactly what happens on the systems where it is not.
Tell us which booking system you run and we will tell you exactly how deep the write goes before you commit to anything.
Start free pilotQuestions about phone booking
If your system publishes a create endpoint, yes: eleven of the nineteen we have checked do, and the table above names the endpoint for each. Where a system exposes no create endpoint, the agent sends a booking link by text during the call instead. We tell you which of those applies to your software before a build starts rather than after.
It queries live availability during the call rather than working from a synced copy. Google Calendar's Freebusy query and Outlook's getSchedule are the clearest examples; most practice-management systems expose an equivalent. A system that can be written to but not read from is the awkward case, and Acuity is the one in our set: it accepts appointments but publishes no read endpoint.
Booking against the live calendar rather than a copy, and holding your rules about buffers, service durations and which practitioner can do what. Where a system supports a reservation step (Boulevard's cart.reserve is the clearest) the slot is held while the rest of the call finishes, which closes the window entirely.
The caller finds out during the call rather than by turning up. A failed write is treated as an escalation: the agent takes the details, tells the caller a person will confirm, and the failure lands in your dashboard with the transcript. A silent failure after the call has ended is the one outcome the build is designed to make impossible.
No, and any vendor claiming otherwise has not read their own integration list. Four of the nineteen systems above are gated behind partner approval, one publishes no public API reference at all, and one has no create endpoint. Where a direct write is not available we say so and use a booking link, which works but is a weaker outcome.
Find out what your booking system actually allows.
The pilot runs about 14 days with no call limit. The integration depth is agreed in writing before the build starts, so what the line can and cannot write is settled at the beginning rather than discovered in week three.
Start free pilotLast updated