Scheduling
Administer your organisation’s scheduling configuration with an API key instead of the admin interface. You can list and cancel scheduled appointments, manage appointment types and their reminders, and configure each doctor’s recurring availability rules. All endpoints are scoped to the organisation that owns the API key. UIDs that belong to another organisation are treated as not found.Permissions
Scheduling endpoints are gated by two permissions:scheduling:read— required for all read (GET) endpoints.scheduling:admin— required for all write endpoints (POST,PATCH,DELETE).
scheduling:admin is not automatically granted scheduling:read;
add both if you need to read and write. Contact your RxScale account manager to
adjust permissions.
All requests authenticate with the X-API-Key header. See
Authentication for details.
Appointments
List Appointments
scheduling:read
Page number (0-indexed)
Number of appointments per page
Filter appointments by doctor UID
Filter appointments by patient UID
Filter by appointment status. One of
held, confirmed, cancelled,
expired, completed, no_show, or all. When omitted, the default
server-side filtering applies.Filter appointments starting at or after this Unix timestamp
Filter appointments starting at or before this Unix timestamp. Must be
greater than
from when both are supplied.Example Request
Response
Response Fields
| Field | Type | Description |
|---|---|---|
data[].uid | string | Scheduled meeting UID |
data[].status | string | Appointment status (held, confirmed, cancelled, expired, completed, no_show) |
data[].doctor_uid | string | Doctor UID |
data[].doctor_display_name | string | Doctor display name |
data[].patient_uid | string | Patient UID |
data[].patient_display_name | string | Patient display name |
data[].appointment_type_uid | string | null | Appointment type UID, if any |
data[].appointment_type_name | string | null | Appointment type name, if any |
data[].meeting_type | string | Meeting type (e.g. CONSULTATION, FOLLOW_UP, INITIAL, REVIEW, ON_DEMAND) |
data[].meeting_format | string | Meeting format (DIGITAL, IN_PERSON) |
data[].start_date | integer | Start time (Unix timestamp) |
data[].end_date | integer | End time (Unix timestamp) |
data[].created_at | integer | Creation timestamp (Unix) |
data[].cancelled_at | integer | null | Cancellation timestamp (Unix), if cancelled |
data[].cancellation_reason | string | null | Reason supplied at cancellation, if cancelled |
totalRegistries | integer | Total number of appointments matching the filter |
totalPages | integer | Total number of pages |
Cancel an Appointment
scheduling:admin
The scheduled meeting UID
Reason for cancelling the appointment (must not be empty)
Example Request
Response
Appointment Types
An appointment type defines a bookable kind of meeting (duration, hold behaviour, room and rebooking strategy).List Appointment Types
scheduling:read
Example Request
Response
Create an Appointment Type
scheduling:admin
Display name (1–255 characters)
Meeting type. One of
CONSULTATION, FOLLOW_UP, INITIAL, REVIEW,
ON_DEMAND.Appointment duration in minutes (1–1440)
How long a tentative hold survives before expiring, in seconds (1–86400)
Default minimum notice required before patients can book this appointment type,
in minutes. Doctor-specific settings can override this value.
Minimum notice required to cancel, in minutes (≥ 0)
Minimum notice required to rebook, in minutes (≥ 0)
Room allocation strategy. One of
persistent_per_provider,
per_appointment.Rebooking mode. One of
same_doctor_only,
any_doctor_same_organisation.Controls which doctors can offer this appointment type. Use
all_available_doctors to include every doctor with availability, or
selected_doctors_only to require an active doctor-specific setting.Whether patients may rebook their own appointments of this type
Whether the appointment type is bookable
Example Request
201 Created with the created appointment type (same shape as a list
entry).
Update an Appointment Type
scheduling:admin
The appointment type UID
Display name (1–255 characters)
One of
CONSULTATION, FOLLOW_UP, INITIAL, REVIEW, ON_DEMANDAppointment duration in minutes (1–1440)
Hold lifetime in seconds (1–86400)
Default minimum booking notice in minutes (≥ 0)
Minimum cancellation notice in minutes (≥ 0)
Minimum rebooking notice in minutes (≥ 0)
One of
persistent_per_provider, per_appointmentOne of
same_doctor_only, any_doctor_same_organisationOne of
all_available_doctors, selected_doctors_onlyWhether patients may rebook their own appointments of this type
Whether the appointment type is bookable
Example Request
200 OK with the updated appointment type.
Delete an Appointment Type
scheduling:admin
The appointment type UID
Example Request
204 No Content on success.
Reminders
Reminders are configured per appointment type and notify a recipient role a fixed number of minutes before the appointment starts.List Reminders
scheduling:read
The appointment type UID
Example Request
Response
Response Fields
| Field | Type | Description |
|---|---|---|
data[].uid | string | Reminder UID |
data[].appointment_type_uid | string | Parent appointment type UID |
data[].recipient_role | string | Who is notified (patient, doctor, admin) |
data[].minutes_before | integer | Minutes before the appointment to send |
data[].send_email | boolean | Whether to send an email |
data[].send_sms | boolean | Whether to send an SMS |
data[].active | boolean | Whether the reminder is active |
Create a Reminder
scheduling:admin
The appointment type UID
Who is notified. One of
patient, doctor, admin.Minutes before the appointment to send the reminder (1–86400, i.e. up to 60
days)
Whether to send an email
Whether to send an SMS
Whether the reminder is active
Example Request
201 Created with the created reminder (same shape as a list entry).
Update a Reminder
scheduling:admin
The appointment type UID
The reminder UID
One of
patient, doctor, adminMinutes before the appointment to send the reminder (1–86400)
Whether to send an email
Whether to send an SMS
Whether the reminder is active
Example Request
200 OK with the updated reminder.
Delete a Reminder
scheduling:admin
The appointment type UID
The reminder UID
Example Request
204 No Content on success.
Availability Rules
Availability rules define a doctor’s recurring weekly bookable windows. Times are expressed as minutes from midnight (for example,540 is 09:00 and 1020 is
17:00).
List Availability Rules
scheduling:read
The doctor UID
Example Request
Response
Response Fields
| Field | Type | Description |
|---|---|---|
data[].uid | string | Availability rule UID |
data[].doctor_uid | string | Doctor UID |
data[].weekday | integer | Day of week (0 = Monday … 6 = Sunday) |
data[].start_time | integer | Start of the window, in minutes from midnight (0–1440) |
data[].end_time | integer | End of the window, in minutes from midnight (0–1440) |
data[].buffer_minutes | integer | Buffer between appointments, in minutes |
data[].valid_from | integer | null | Optional start of validity (Unix timestamp) |
data[].valid_until | integer | null | Optional end of validity (Unix timestamp) |
data[].active | boolean | Whether the rule is active |
Create an Availability Rule
scheduling:admin
The doctor UID
Day of week (0 = Monday … 6 = Sunday)
Start of the window, in minutes from midnight (0–1440)
End of the window, in minutes from midnight (0–1440)
Buffer between appointments, in minutes (≥ 0)
Optional start of validity (Unix timestamp)
Optional end of validity (Unix timestamp)
Whether the rule is active
Example Request
201 Created with the created availability rule (same shape as a list
entry).
Update an Availability Rule
clear_* flag rather than a value.
Required permission: scheduling:admin
The doctor UID
The availability rule UID
Day of week (0 = Monday … 6 = Sunday)
Start of the window, in minutes from midnight (0–1440)
End of the window, in minutes from midnight (0–1440)
Buffer between appointments, in minutes (≥ 0)
Set the start of validity (Unix timestamp)
Set the end of validity (Unix timestamp)
Whether the rule is active
Clear the existing
valid_from bound (set it to null)Clear the existing
valid_until bound (set it to null)Example Request
200 OK with the updated availability rule.
Delete an Availability Rule
scheduling:admin
The doctor UID
The availability rule UID
Example Request
204 No Content on success.