A client profile saved with timeZone America/Edmonton, America/Yellowknife, America/Inuvik or\nCanada/Mountain now reads back as America/Edmonton instead of America/Denver, and one saved\nwith America/Vancouver or Canada/Pacific reads back as America/Vancouver instead of\nAmerica/Los_Angeles. Time zone answers from GET /api/v1/forms/{id} gain \"Calgary, Edmonton\" and\n\"Vancouver, Victoria\", and the US options now read \"Denver, Salt Lake City\" and \"Los Angeles, Seattle\".
PATCH /api/v1/appointments/{id}, PATCH /api/v1/group-appointments/{id} and PATCH /api/v1/group-appointments/{appointmentId}/participants/{clientId} no longer report success when a resource item you asked for could not be attached; the request fails instead of returning 200 with the resource silently missing. Moving an appointment and assigning a resource item in the same request now also attaches it when that resource is only busy at the appointment's previous time.
Creating and updating appointments, group appointments and group participants is now available to\nevery practice, and the group appointment operations appear in the API reference for the first time.
", "url": "https://zandaapi.zandahealth.com/docs/changelog/2026/09/28/release", "title": "28 September 2026", "summary": "Appointment write endpoints are published", "date_modified": "2026-09-28T00:00:00.000Z", "tags": [ "Changed" ] }, { "id": "https://zandaapi.zandahealth.com/docs/changelog/2026/09/23/release", "content_html": "Payment responses now carry created, when the payment was created, and userModified, when its\ndetails or invoice allocations were last changed. userModified is null until the payment is first\nchanged. Prefer it over lastModified for detecting edits: lastModified is broader and also moves\nwhen the record is rewritten without any of those values changing.
Payment responses now carry an invoices collection: one entry per invoice the payment was\nallocated to, with a link to it and the amount allocated. An unallocated payment returns an empty\ncollection.
Responses using application/vnd.zandaapi.hateoas+json now advertise the write operations available,\nso you can act by following a link rather than building the URL yourself. A collection carries\ncreate; the operations that act on a record — update, delete and the like — are on that record's\nown response, so fetch it and follow the links it returns.
Added GET /api/v1/personal-appointments and GET /api/v1/personal-appointments/{id}, which list\nthe practice's personal appointments and fetch one by id.
Added GET /api/v1/practitioner-roster-overrides and\nGET /api/v1/practitioner-roster-overrides/{id}, which return the one-off changes made to a\npractitioner's recurring roster: a day off, a conference, an extra evening clinic. Each override\ngives the date range and the daily time window it covers, whether it adds or removes availability,\nand whether those hours can be booked online. Filter by practitioner, location, active status,\navailability, online bookings, or the date an override is in effect.
Endpoints that are still in beta now show a [BETA] prefix or a BETA chip in the documentation pages.
Added GET /api/v1/practitioner-roster and GET /api/v1/practitioner-roster/{id}, which return a\npractitioner's recurring working pattern: the date range, the location, how often the pattern\nrepeats, and the time slots for all seven weekdays, including any services a slot excludes from\nonline booking. Filter by practitioner, location, active status, availability, online bookings, or\nthe date a roster is in effect.
POST /api/v1/invoices and PATCH /api/v1/invoices/{id} are out of limited release and enabled for\nall practices. Request and response shapes are unchanged, so an integration built against them\nduring the limited release needs no update.
POST /api/v1/appointments takes billableItemIds, the items the appointment is invoiced for, as\nreturned by GET /api/v1/billable-items. Order matters: the first identifier becomes the\nappointment's service. Send none and the appointment is not invoiced.
PATCH /api/v1/appointments/{id} takes billableItemIds as the full set the appointment is invoiced\nfor, replacing whatever is there. Omit it to leave the invoice untouched, or send an empty array to\nclear the billable items, which leaves the invoice with a zero total rather than deleting it.\nAnything else on the invoice, such as a session-pack session or a card surcharge, stays as it is.
page has been removedThe page parameter no longer exists on any list endpoint. Every list is paged with cursor. This\nis a breaking change to any request that still sends page.
Read cursor from the response and send it back to fetch the next page; omit it to start from the\nbeginning. pageSize is unchanged and still sets how many records a page holds. Paging by cursor is\nforward-only, so there is no page number to jump to and no total to divide.
Before:
\nGET /api/v1/invoices?page=3&pageSize=25
After:
\nGET /api/v1/invoices?cursor=CURSOR_FROM_PREVIOUS_RESPONSE&pageSize=25
POST /api/v1/group-appointments/{appointmentId}/participants adds a client to an existing group\nbooking.
POST /api/v1/group-appointments creates a group appointment.
DELETE /api/v1/group-appointments/{appointmentId}/participants/{clientId} removes one participant\nfrom a group booking, leaving the other participants untouched.
locationId is replaced by a locations collectionOn GET /api/v1/resource-items and GET /api/v1/resource-items/{id}, the single locationId field\nis gone. A resource item now returns locations, a list of the locations it is available at, each\nwith an id, a name and a link. This is a breaking change to the resource item response.
A resource can be shared across locations, which the single field could not express. Read\nresourceItem.locations and match on the entry you need instead of comparing locationId. The\nlocationId filter on the list endpoint is unchanged and now matches an item at any of its\nlocations.
Before:
\n\"locationId\": 3
After:
\n\"locations\": [
{
\"id\": 3,
\"name\": \"Coburg\",
\"links\": [{ \"href\": \"/api/v1/locations/3\", \"rel\": \"self\", \"method\": \"GET\" }]
},
{
\"id\": 7,
\"name\": \"Fitzroy\",
\"links\": [{ \"href\": \"/api/v1/locations/7\", \"rel\": \"self\", \"method\": \"GET\" }]
}
]
scheduleReminder may be setOn PATCH /api/v1/appointments/{id} and\nPATCH /api/v1/group-appointments/{appointmentId}/participants/{clientId}, scheduleReminder is\nrejected once the appointment's start time has passed, and while the attendance state is anything\nother than Pending or Confirmed unless a reminder has already been sent. Setting it to true\nalso requires a client who can receive reminders. Omit the property in those cases. The rules now\nmatch the ones the Zanda app applies.
POST /api/v1/invoices no longer rejects an invoice whose practitioner has since been deactivated,\nwhich matches what the practice can do in the app.
Paging through GET /api/v1/invoices with cursor could still fail rather than return a page for\nsome practices; this is now fixed.
POST /api/v1/client-profiles/clients and PATCH /api/v1/client-profiles/clients/{id} are out of\nlimited release and enabled for all practices. Request and response shapes are unchanged, so an\nintegration built against them during the limited release needs no update.
Creating or updating a profile with a lookup id that is no longer active, such as an archived\nclassification, category or status, is rejected with 400. Read the current options from the\nmatching reference-data endpoint.
referrerType is now an objectOn GET /api/v1/referrals and GET /api/v1/referrals/{id}, the referrerType field has changed\nfrom a plain text name to an object with an id, a name, and a link to the matching referrer type.\nThis is a breaking change to the referral response.
If you currently read the referrer type's name, change referral.referrerType to\nreferral.referrerType.name. You can now also use referral.referrerType.id to fetch it from\nGET /api/v1/referrer-types/{id}, or match it against the GET /api/v1/referrer-types list. As\nbefore, referrerType is null when a referrer has no type set.
Before:
\n\"referrerType\": \"General Practitioner\"
After:
\n\"referrerType\": {
\"id\": 42,
\"name\": \"General Practitioner\",
\"links\": [{ \"href\": \"/api/v1/referrer-types/42\", \"rel\": \"self\", \"method\": \"GET\" }]
}
GET /api/v1/note-templates lists the practice's note templates.GET /api/v1/form-templates and GET /api/v1/form-templates/{id} list and fetch form templates.PATCH /api/v1/group-appointments/{appointmentId}/participants/{clientId} updates a single\nparticipant's appointment within a group booking, leaving the other participants untouched.
PATCH /api/v1/group-appointments/{id} edits a group appointment.
GET /api/v1/notes and GET /api/v1/notes/{id} return client notes. The list returns note metadata;\nfetch a single note to read its answers.
POST /api/v1/payments, PATCH /api/v1/payments/{id} and DELETE /api/v1/payments/{id} are out of\nlimited release and enabled for all practices. Nothing about them changed on the way out, so an\nintegration built against them during the limited release needs no update.