Developer API
Connect your own system to MedOS, from booking to the clinical record.
Live for every MedOS client, on any plan: a server-side REST API for booking, queues and session packs, and for hospital and clinic systems keeping patients, appointments, prescriptions, vitals and documents in step with MedOS.
Your first call
One header, and your clinic comes back.
curl -s "https://api.medos.one/v2/workspaces" \
-H "x-api-key: $MEDOS_API_KEY"Booking
Take bookings from your own app or website.
- Appointments
- Available slots per doctor, book, reserve a slot with checkout, confirm payment, reschedule, change status and cancel with an optional refund.
- Queue (QMS)
- A doctor’s queue shifts for a date, a token reserved for a future shift, or a token in the queue that is running now.
- Session packs
- The clinic’s pack catalogue, a standalone pack purchase with checkout, and payment confirmation.
- Booking without OTP
- For a backend that has already identified its patient: book, reserve or take a queue token with no one-time code.
Back office and clinical records
Keep your hospital or clinic system in step with MedOS.
- Appointment and queue read-back
- Read one appointment, search appointments by filter, a practitioner’s shaped day, queue history, a day’s queue and where a running queue has reached.
- Patients
- Find a patient by MRN, email or phone, read one patient and their visit history, the workspace roster, and create-or-update to keep your master patient index in step.
- Clinical records
- Write, amend and read prescriptions, fetch the rendered prescription PDF, record vitals and medical history, list and remove documents, and search the medicine catalogue.
- Locations and configuration
- Locations and rooms, follow-up policies, practitioners and their shifts, scheduled and queue configuration, booking policy and accepted payment methods.
- Workspace, staff and profiles
- The whole clinic in one read, the patient-form schema, staff users, and practitioner public profiles with gallery, FAQs and SEO fields.
The trust model
- A secret key
- Every request carries a Developer API key in the x-api-key header. It lives on your server, never in a browser.
- An IP allowlist
- Requests from any address not registered on the key are refused, so a leaked copy of the key is useless.
- Scoped by the key
- The workspace comes from the key, not the request, so nothing you send can reach another clinic’s data.
- Documented routes only
- Each route is opened to API keys individually; anything else answers 403. Keys rotate with no downtime.
- Access per operation
- Back-office and clinical operations are enabled per workspace, one at a time: reading a prescription and writing one are separate grants.
- The real author on every write
- Every write names the staff member it is made for, so the audit trail shows who wrote each prescription or edit, not one integration account.
What the API reaches
- Patient records
Visits, last seen, next appointment, outstanding balance, notes, prescriptions and activity, on one record. Nothing is re-entered at the desk.
Read more - Digital prescriptions
The prescription is written inside the consultation, on the doctor’s own header, signature and stamp, and reaches the patient as a PDF or on WhatsApp as soon as it is saved.
Read more - Queue management
Each doctor’s OPD runs as a shift with a live queue. The desk sees who is consulting, who is next and how many are left; patients follow the same queue from a link.
Read more - Integrations
Reminders go out from your own WhatsApp number, appointments land in Google Calendar, video links come from Meet or Zoom, and payments go to your own account.
Read more