Recipes
6 flows, each written as the exact sequence of calls it takes, in the order you make them. Pick one to see the calls, the fields that matter, and the mistakes it specifically invites.
Writes are shown, never sent. These are reference call sequences — the backend behind this API is wired to the production system, so nothing here is runnable from the page itself. Every write step below (7 across all recipes) is what your own backend calls, not something this page executes.
Book and pay for a consultation
The path most integrations only ever need: find a clinician, check live availability, create the patient, book, take the money — in one call.
The calls, in order
- 1
Load reference data once, cached. You need a campus id for the booking, and these ids are stable.
- 2
Filter the clinician directory to what the patient asked for. Take the doctor id.
specialtycitylanguagelimitoffset - 3
Read live availability for that clinician, with the price already on each slot. Never cached. Take the slot id.
doctorIdfromtocampusId - 4
Create (or resolve, it's idempotent by phone) the patient record. Store the id you get back.
phonepatientNamecontactName - 5
Bind slot, patient and campus into a confirmed appointment and receive a hosted payment link in the same response.
patientIdslotIdcampusIdconsultationTypeIdpaymentMode - 6
Read the booking back before you tell the patient it is confirmed.
patientId
Gotchas
- •Reading availability does not hold a slot. Between your read and your booking call, someone else can take it — handle the failure and re-read availability rather than retrying the same slot.
- •`paymentMode: online` is what pairs with a usable payment link in the response. `cash` returns no link.
- •Store the patient id and the slot id in your own records. Nothing here maps a phone number back to a patient.
Need a flow that isn't here?
That gap is usually ours to close — tell us what you're building.
Contact us