What we need from your backend

The agent layer is only as good as its writes. Here is what the engine needs from your backend, and what it does with it. One integration powers agent bookings, phone and WhatsApp alike.

The five capabilities

1. Real-time availability. A way to read open slots per practitioner, service and location. Polling an export file is not availability; an endpoint is.
2. Patient matching that survives fuzzy input. Patients spell their names to a voice agent and paraphrase them to a chat agent. We need search by name + date of birth or phone, tolerant of near-misses, so bookings attach to the right record.
3. Idempotent, patient-linked writes. Creating an appointment must be safe to retry and must link the patient record. Duplicate bookings from a retried request are the fastest way to lose a practice's trust.
4. Cancellation as a status, not a delete. Reschedules and cancellations should mark, not erase, so practices keep their audit trail and fee policies work.
5. Webhooks (or a change feed). When the practice moves an appointment in your UI, the reception must know before the patient's assistant asks about it.

Two integration paths

You have an API: we integrate against it. REST is typical; the shape above matters more than the style.

You have no public API: still fine. Our reference deployment runs against a closed practice system with no open API, with real calendar writes. It is more work on our side, not yours, and it is proven in production.

We build and maintain the integration. Your engineering cost is an integration call, sandbox access, and code review at your pace.

What happens on our side

The reception agent handles the conversation: triage, availability questions, series bookings where the vertical needs them, SMS verification, confirmation read-back, and the write. Transcripts and events are available to the practice, retention is configurable, and emergencies escalate per practice instructions rather than being handled by the agent.