Bookings & appointments

Overview

Bookings work through ready-made connectors for the system you book people in — Cliniko, Cal.com, Acuity, Microsoft Bookings, Mindbody, ResDiary, Jobber and many more. When a connector that holds bookings is used to verify customers, the platform adds a My Bookings tool to your bot automatically. That tool is verified-only: it runs only after the customer has passed the one-time-code check.

• Read-only. The bot reads appointment times, the service and the status. It does not book, move or cancel appointments in your system.
• Minimal. Clinical notes, treatment records and case notes are never mapped. The bot sees when, what and whether it is confirmed — nothing more.
• Honest. If the system cannot be reached, the bot says it cannot check right now; it never tells someone they have no appointment because a lookup failed.

How a booking lookup works

1. 1
   The customer asks about an appointment. The bot asks for their full name and an email address or mobile number.
2. 2
   The platform finds the customer in your booking system by email or mobile, checks the name (the surname must match and the first name must match or start with the same letter) and one more detail, and sends a one-time code to the contact details your system holds — by text when your plan includes SMS, otherwise by email.
3. 3
   The customer types the code. A session is created for 30 minutes, bound to the customer record your system returned.
4. 4
   The bot calls POST https://www.siluxchat.com/api/connect/{connection_id}/bookings with the session token. The platform reads the customer’s bookings from your system with your stored, encrypted credentials and maps them to the standard shape.
5. 5
   The bot answers: “Your next appointment is a physiotherapy follow-up on Thursday 2 October at 10:30, and it is confirmed.”

The identity checks are explained in full in Customer identity verification & OTP.

The booking shape

Every booking system is mapped to the same core fields. id and start must be present for a row to count. Many connectors add useful extras — an end time, a location, a party size for restaurants, or a cancelled / did-not-arrive flag for clinics. Each connector’s page lists exactly which fields it maps.

The bookings endpoint the bot calls

{
  "success": true,
  "bookings": [
    {
      "id": "84213",
      "start": "2026-10-02T10:30:00+01:00",
      "end": "2026-10-02T11:00:00+01:00",
      "service": "Physiotherapy follow-up",
      "status": "confirmed"
    }
  ]
}

A safety net removes any row that names a different customer’s email address, whatever the booking system’s search returned.

Bookings from your own system

Account Connect — the five endpoints you can build on your own platform — covers identity, the account summary, orders and invoices. It has no separate bookings endpoint. If appointments live in your own system, include them in your /account-summary response: the bot reads whatever fields you return.

{
  "success": true,
  "account": {
    "account_number": "C1001",
    "name": "Test Customer",
    "status": "active",
    "upcoming_bookings": [
      { "id": "B-3310", "start": "2026-10-02 10:30", "service": "Annual service", "status": "confirmed" },
      { "id": "B-3348", "start": "2026-10-16 14:00", "service": "Follow-up visit", "status": "provisional" }
    ]
  }
}

• Include future bookings only, soonest first, and no more than the next five or so. The bot reads roughly the first 2,000 characters of a response.
• Give times in the customer’s local time with a clear format, and say whether a booking is confirmed or provisional.
• Leave out practitioner notes, reasons for visit and anything clinical.

You can see a real account-summary call against the demo — the same request your own endpoint must answer:

# export SESSION=<the session_token returned by POST /verify-otp>
: "${SESSION:?export SESSION first}"
curl -s -X POST "https://www.siluxchat.com/api/account-connect-demo/v1/account-summary" \
  -H "X-API-Key: demo-account-connect-key" \
  -H "Content-Type: application/json" \
  -d "{\"session_token\":\"$SESSION\"}"

{
  "success": true,
  "account": {
    "account_number": "C1001",
    "status": "active",
    "plan": "Business Phone Line — 12 months",
    "monthly_price": "£19.95",
    "contract_end": "2027-03-31",
    "balance_due": "£0.00",
    "name": "Test Customer"
  }
}

Booking connectors by sector

Each of these connectors reads a verified customer’s bookings. The connector pages explain where to create the key and which read-only permissions or OAuth scopes to grant. Where the vendor has no customer search (Cal.com, Google Calendar, Workiz), the customer is verified by their name and the email on their own bookings, and the code is emailed to that address.

Health, dental and veterinary practices

Practical advice for practices

• Patients are found by the email or mobile number on their patient record, so keep those details current — they are also where the one-time code is sent.
• Describe cancellation and rescheduling rules in your knowledge base. The bot reads bookings but cannot move them, so it should direct patients to your booking link or reception.
• Some practice systems (for example EMIS, SystmOne, Vision and several dental systems) do not offer third-party access to appointment records at all. The connectors page lists them honestly, with the alternative routes.
• Review Security & data protection for UK GDPR guidance on special-category data.

Errors and edge cases

More detail: Troubleshooting & error reference.

Get help

Not sure whether your booking or practice system can connect, or which scopes to grant? Email support@siluxcall.co.uk with the system name — our integration team will guide you through it.