AI Chatbot Acuity Integration That Books Real Appointments, Not Guesses

First decision: send visitors to Acuity, or book them inside the chat?

Acuity Scheduling already handles the difficult parts of booking well. It knows how long each service runs, which staff member or room offers it, how much notice you require, which intake questions to ask and whether payment is due up front. A good chatbot integration borrows all of that instead of rebuilding it. The first design choice is how much of the booking actually happens inside the chat window.

There are two workable patterns plus a hybrid. We choose per appointment type rather than once for the whole account, because a free fifteen-minute consult and a prepaid package session have very different needs.

The hybrid uses the API only to read. When someone asks whether anything is open Thursday afternoon, the bot checks real availability and answers truthfully, then passes the visitor to Acuity to finish. That removes the most common failure on scheduling websites, a confident chatbot describing openings it made up, without taking on the responsibility of creating appointments.

The Acuity data a chatbot actually touches

Acuity organizes an account around a small set of objects. A dependable integration maps each one explicitly rather than letting the language model infer structure from your website copy.

• Appointment types. Each carries a name, duration, price, category and the list of calendars that offer it, and some are private, reachable only by direct link. The connector reads the type list on a schedule, keeps an allow-list of which types the bot may offer, and matches plain-language requests such as ‘the longer deep tissue one’ to a specific type ID.
• Calendars. In Acuity a calendar usually stands for a staff member, a room or a location, and each can have its own time zone. When only one calendar offers a type, the bot never asks the visitor to choose a provider. When several do, it asks once and accepts ‘no preference’.
• Availability. Openings are looked up per appointment type and, optionally, per calendar: first which dates in a month have space, then which times exist on a chosen date. Acuity applies your minimum notice, advance booking window, buffers and blocked-off time before it answers, so the bot performs no scheduling arithmetic of its own.
• Appointments. Creating one needs the type, the start time and the client’s name and email, plus phone and form answers when your settings demand them. Existing appointments can be rescheduled or canceled through the same interface.
• Intake forms. Questions are attached to appointment types, and every field has its own ID. Answers gathered in chat must be submitted against those IDs, and a missing required field means Acuity refuses the booking.
• Clients. Acuity builds a client list from bookings. The bot rarely needs to read it, and we keep it that way, because a public chat window able to look up other people’s details is a liability.

Exact endpoint names, parameter formats and which features your subscription opens to the API are confirmed against Acuity’s current developer documentation and your own account during scoping, before anything is quoted.

Access: API credentials, OAuth, and where the key lives

For a single business connecting its own account, Acuity’s API is normally reached with the account’s user ID and an API key. Acuity also supports OAuth for software that connects to many separate Acuity accounts; that route matters to app developers more than to a studio wiring up one website. We confirm which applies to you at the outset.

Either way, treat the credential as a master key. It can read client records, create bookings and cancel them. So we handle it like one:

• It is stored as a server-side secret and used only by the integration service. It never appears in the chat widget’s JavaScript, in page source, or in anything sent to the AI model.
• The model never contacts Acuity itself. It asks our server to run one of a few named actions, such as check_availability or create_booking, and the server decides whether that request is permitted.
• You keep ownership of the Acuity account. If the engagement ends, regenerating the key in Acuity cuts off the old one.
• We log which action ran, when, and whether it succeeded, without copying visitors’ intake answers into general-purpose logs.

API and webhook access can depend on your Acuity plan. If your current plan does not include them, the scheduler hand-off pattern still works, and we will explain in plain terms what an upgrade would unlock before you decide anything.

What a well-built booking conversation looks like, turn by turn

The studio below is invented to illustrate the flow. A two-therapist massage studio runs Acuity with four appointment types, one intake form and a 24-hour cancellation policy. A visitor opens the chat late on a Tuesday evening.

1. Understand the request. The visitor writes, ‘Any 90 minute deep tissue this weekend?’ The bot maps that to the 90-minute deep tissue type and treats ‘this weekend’ as a date window resolved in the studio’s time zone.
2. Ask only what is missing. Both therapists offer that service, so the bot asks whether the visitor has a preference. The answer is no.
3. Query, never guess. The server asks Acuity for Saturday and Sunday openings for that type across both calendars. The bot offers three of the returned times, spread across the two days, instead of dumping every slot into the chat.
4. Collect details conversationally. Once a time is picked, the bot asks for first and last name, email and mobile number, then the two required intake questions, worded naturally but mapped to their exact field IDs.
5. Re-check the slot. Just before booking, the server confirms the chosen time is still open. If someone else took it minutes earlier, the bot apologizes and offers the nearest alternatives.
6. Create the appointment. The server submits the booking to Acuity and reads the response.
7. Confirm from the record. The confirmation repeats the date, time, therapist and address as Acuity returned them, and mentions that the studio’s usual confirmation email is on its way.
8. Fail safe. If any step errors, the visitor receives a direct scheduling link for the same appointment type, so a technical problem never costs the booking.

Two rules sit underneath every turn: the model may not state an available time that did not come from Acuity during this conversation, and it may not say a booking exists until the server holds a successful response carrying an appointment ID.

After the booking: webhooks keep the chatbot honest

A booking is rarely a single event. People reschedule, cancel, or book again by phone, and your front desk edits appointments inside Acuity directly. A chatbot that only writes and never listens soon works from stale information.

Acuity can notify a URL when appointments are scheduled, rescheduled, canceled or otherwise changed. The notification identifies the appointment rather than carrying every detail, so our endpoint acknowledges it quickly and then fetches the full record through the API. What happens next depends on your setup:

• Scheduled. The chat lead is marked converted so no follow-up message nags someone who already booked, and the booking is pushed to your CRM if you use one.
• Rescheduled. The stored date is updated so any reminder or follow-up logic runs against the new time.
• Canceled. Optionally, the bot offers a gentle rebooking path the next time that visitor chats, or staff are alerted when a sought-after slot opens.

Three safeguards protect the endpoint. We verify the signature Acuity attaches to each notification before trusting its contents. Processing is idempotent, keyed on appointment ID and action, because webhook senders can deliver the same event twice. And bookings the bot creates are tagged through a field or note agreed during scoping, so your reports can separate chat bookings from those made on the scheduling page or over the phone.

Six Acuity details that trip up naive chatbot integrations

1. Time zones. A calendar set to Central time and a visitor browsing from Arizona read ‘3:00’ differently. The bot names the zone with every time it offers and converts when the visitor’s differs, relying on the offset in Acuity’s response rather than the server clock.
2. Paid appointment types. When a service requires payment at booking, a server-side booking can sidestep the checkout the client would normally see. Unless you deliberately want to collect payment later, those types go to the scheduler.
3. Packages, subscriptions and gift certificates. Codes and prepaid balances are applied inside Acuity’s own client flow. The bot recognizes phrases like ‘I bought a package’ and hands off instead of creating an appointment that ignores the balance.
4. Classes and group sessions. Events with a fixed start time and limited seats are looked up differently from one-to-one appointments, and the useful answer is how many places remain, not a list of times.
5. Administrator-level booking. Acuity’s API can book with the relaxed rules an administrator enjoys, which can override your notice and availability limits. That suits staff tools and is wrong for a public chat, so our connector books with client-level rules only.
6. Duplicate client records. A regular who types a work email instead of a personal one can become a second client in Acuity. We normalize formatting and, where it matters, ask returning visitors which email they used before.

How we test before a real client books through the bot

• A hidden test calendar. We ask you to create a test calendar or a hidden appointment type so bookings made during testing never land in a real person’s day.
• A scripted scenario set. Dozens of written conversations: vague dates (‘sometime next week after work’), a provider who does not offer the requested service, a visitor in another time zone, a required intake question answered with nonsense, a parent booking two children back to back.
• Record comparison. For every booking the bot claims, we open Acuity’s admin view and compare type, calendar, time, contact details and form answers field by field.
• Lifecycle checks. We reschedule and cancel test appointments from inside Acuity and confirm the webhook path updates the bot’s records.
• Failure drills. We force the conflict case by taking a slot by hand mid-conversation, and we simulate Acuity being unreachable to confirm the scheduler-link fallback appears.
• Phone-first review. Most booking chats happen on phones, so slot buttons and question prompts are checked on small screens and with a screen reader.

After launch we watch the first stretch of real bookings closely, reconciling chat-created appointments against Acuity until both sides agree without exception.

Client details and intake answers: collect less, keep less

Intake forms often ask personal questions about injuries, allergies or the reason for a visit. Once those questions move into a chat window they pass through more systems than a plain scheduling page does, including the AI model provider. We design with that in mind:

• The bot asks only what Acuity requires for that appointment type. Optional questions can stay on Acuity’s own forms or be covered at the visit.
• Answers are sent to Acuity and stripped from any transcript we retain, or transcripts are not retained at all, whichever you prefer.
• If your practice handles health information subject to specific regulation, we raise it on the first call so your compliance adviser can review the entire chain, chatbot platform included, before anything is built. We are not your lawyer, and the design should not rest on assumptions.

How EVOTECH IT LLC scopes and builds your Acuity chatbot

Behind this work is EVOTECH IT LLC: two-plus decades in business, a 5.0 Google rating, and US staff near Houston who build web, software and AI projects remotely for clients throughout the country. An Acuity chatbot project runs in this order:

1. Free consultation. A phone or video call where you describe how clients book today and where you lose them.
2. Account review. With your permission we examine appointment types, calendars, forms, payment settings and plan level, then list which types suit hand-off and which suit API booking.
3. Written, fixed-scope quote. It names every appointment type the bot will handle, the pattern for each, the webhook events we will process and the systems we will notify.
4. Build. The server-side connector, the conversation design, the allow-list of types and the fallback path.
5. Testing on the hidden calendar with the scenario set, followed by a review of results with you.
6. Launch and watch. We monitor early bookings and adjust wording wherever visitors hesitate.
7. Handover. Plain-language notes on what the bot can do, how to add a new appointment type to its allow-list, and how to revoke its access.

If you are still choosing a scheduler, our Calendly chatbot integration page explains how that platform differs, and our AI chatbot development overview covers everything else a business chatbot can take on. To talk it through, phone (832) 359-2425 or request a free consultation.

Related services

Frequently asked questions