Available slots by doctor
The same slot grid, with the doctor in the path instead of the query.
GET /v1/appointments/doctors/:doctorId/available-slotsAn alias of GET /v1/appointments/available-slots
for clients whose routing is organised per doctor. Same upstream call, same
response, two differences in how you address it.
available-slots | This route | |
|---|---|---|
| Doctor | ?doctorId= | :doctorId path segment |
| Date | ?appointmentDate= | ?date= |
Everything else — mode, durationTierId, durationMins, patientId,
patientCountryCode, patientPhoneNumber, followUp, patientTimezone — is
accepted identically and means the same thing.
Path parameters
| Name | Type | Required | Description |
|---|---|---|---|
doctorId | number | Yes | The practitioner. |
Query parameters
| Name | Type | Required | Description |
|---|---|---|---|
addressId | number | Yes | The clinic location. |
date | string | Yes | YYYY-MM-DD in the clinic's timezone. Note the name — not appointmentDate. |
| … | Every optional parameter from Available slots. |
Try it
/v1/appointments/doctors/:doctorId/available-slotsPath
Query
GET /v1/appointments/doctors/4/available-slots?addressId=1&date=2026-10-12https://api.medos.oneUse a dedicated test key, and put your browser's address on its allowlist
A Developer API key authenticates on its own, so it only works from the addresses registered against it — and this page calls from your browser, not your servers. Unless your own public address is on the list you get a 403 naming it, which is the allowlist doing its job. Your browser may also reach us over IPv6 even when your server does not, so the address in the error is often not the one you expected. The key here is kept in memory only and never written to storage, but create a test key for it and deactivate that key when you are done.
Request
curl -sG "https://api.medos.one/v1/appointments/doctors/4/available-slots" \
-H "x-api-key: $MEDOS_API_KEY" \
--data-urlencode "addressId=1" \
--data-urlencode "date=2026-09-20"Response
Identical to Available slots,
including the dual patient* renderings and their caveat: book with the clinic
time, never the patient time.
Pick one and stay on it
There is no behavioural reason to prefer either route. Mixing them in one
codebase mainly buys you the date / appointmentDate mistake.