Skip to content →
Core workflowsAppointments
GitHub
Core workflows

Appointments

Request, schedule, progress, update, and cancel appointments through the configured transport.

Request lifecycle

An appointment request is separate from the appointment it may create. Requests preserve source, urgency, preferred window, assignment, and the final scheduling response.

01
Queued

A message, test, API call, or manual action requests care.

02
Scheduled

The selected transport accepts the booking and creates an appointment.

03
Progressed

A due appointment completes or becomes a no-show.

04
Updated

Connector transports can mirror completion or no-show to the remote system.

Appointment types

FieldValues
Kindgeneral, follow-up, urgent, lab, video
Urgencyroutine, soon, urgent
Statusscheduled, completed, cancelled, no-show, reschedule-requested
Request sourcephone, online-booking, practice-api, test-user, manual, message

Requests may also define an earliest and latest time plus a free-form window note.

Progress and updates

When simulated time reaches a scheduled start, Praxis determines completion or no-show from the actor and seeded randomness. If the booking transport is a connector and it implements booking.update, the substrate can mirror the status to the remote record.

Cancellations

A local-sim cancellation commits immediately. A connector or mock-random cancellation stays queued until its transport confirms success. Failed cancellation attempts leave the appointment unchanged and create recovery work.

Request a cancellation
curl -X POST http://localhost:3000/api/simulation/appointments/cancel \
  -H 'Content-Type: application/json' \
  -d '{"appointmentId":"appt_…","source":"manual","reason":"Patient requested"}'