Require proof of the final system state, not just a successful-looking conversation or tool response. Our recommended booking sequence is: identify, check eligibility, retrieve availability, obtain confirmation, write, verify and then report the result.
Open Dental’s API documentation illustrates why implementation detail matters: it provides separate appointment retrieval, slot-search, creation and update operations, and describes differences between API slot search and the application’s appointment search. (opendental.com)
Use a booking-integrity test pack:
| Synthetic scenario | Required acceptance evidence |
|---|---|
| Another user takes the offered slot | No false confirmation; a valid alternative or escalation. |
| Caller changes location | Availability and rules are checked for the new location. |
| Same request reaches the system twice | No duplicate transaction. |
| Write times out | The system checks whether it succeeded before retrying. |
| Caller reschedules | The intended original record changes without an unintended second booking. |
| Integration fails after the conversation begins | No claim that the appointment is confirmed. |
| Name is misheard | Correction reaches the operational record, not only the transcript. |
| Wrong appointment duration is suggested | The rule violation is blocked or escalated. |
Make duplicate prevention and uncertain-write recovery explicit integration requirements; do not assume the underlying product supplies them automatically.
Also record software versions. Open Dental’s version 26.2 page, initially released as beta on 6 August 2026, lists additional appointment blockout-conflict checks. That is a concrete reason to verify the deployed version rather than assume all installations behave alike. (opendental.com)