Approved appointment mapping
The workflow is bound to the configured practice, appointment type, calendar, and timezone. It does not choose an arbitrary service because a model suggested one.
Scheduling
Klyniq connects a supported scheduling system to one approved workflow. The model can discuss the appointment, but server-side rules control which tenant, appointment type, calendar, and action are actually authorized.
How Klyniq works
The goal is not simply to call a calendar API. The goal is to make the booking path correct, reviewable, and hard to execute twice.
The workflow is bound to the configured practice, appointment type, calendar, and timezone. It does not choose an arbitrary service because a model suggested one.
The receptionist offers times returned by the live scheduling integration. If availability cannot be verified, it does not invent a slot.
The visitor sees the specific service, date, time, and booking identity before the consequential action is allowed to run.
A current server-side proposal must be explicitly confirmed. A vague or stale 'yes' is not enough to authorize a different booking.
Booking attempts use a deterministic identity and server-side execution controls so a retry or repeated confirmation does not blindly create another appointment.
If the scheduling provider returns an uncertain result, Klyniq does not automatically retry and risk a duplicate. The outcome is recorded for reconciliation or human review.
For technical review
The public docs explain what a connection grants, what it does not grant, how booking requests are authorized, and which API contracts are intended for integration work.