A client profile saved with timeZone America/Edmonton, America/Yellowknife, America/Inuvik or Canada/Mountain now reads back as America/Edmonton instead of America/Denver, and one saved with America/Vancouver or Canada/Pacific reads back as America/Vancouver instead of America/Los_Angeles. Time zone answers from GET /api/v1/forms/{id} gain "Calgary, Edmonton" and "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 every practice, and the group appointment operations appear in the API reference for the first time.

Payment responses now carry created, when the payment was created, and userModified, when its details or invoice allocations were last changed. userModified is null until the payment is first changed. Prefer it over lastModified for detecting edits: lastModified is broader and also moves when the record is rewritten without any of those values changing.

Invoice allocations on payments​

Payment responses now carry an invoices collection: one entry per invoice the payment was allocated to, with a link to it and the amount allocated. An unallocated payment returns an empty collection.

Responses using application/vnd.zandaapi.hateoas+json now advertise the write operations available, so you can act by following a link rather than building the URL yourself. A collection carries create; the operations that act on a record — update, delete and the like — are on that record's own response, so fetch it and follow the links it returns.

Personal appointments​

Added GET /api/v1/personal-appointments and GET /api/v1/personal-appointments/{id}, which list the practice's personal appointments and fetch one by id.

Practitioner roster overrides​

Added GET /api/v1/practitioner-roster-overrides and GET /api/v1/practitioner-roster-overrides/{id}, which return the one-off changes made to a practitioner's recurring roster: a day off, a conference, an extra evening clinic. Each override gives the date range and the daily time window it covers, whether it adds or removes availability, and whether those hours can be booked online. Filter by practitioner, location, active status, availability, 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.

Practitioner rosters​

Added GET /api/v1/practitioner-roster and GET /api/v1/practitioner-roster/{id}, which return a practitioner's recurring working pattern: the date range, the location, how often the pattern repeats, and the time slots for all seven weekdays, including any services a slot excludes from online booking. Filter by practitioner, location, active status, availability, online bookings, or the date a roster is in effect.

POST /api/v1/invoices and PATCH /api/v1/invoices/{id} are out of limited release and enabled for all practices. Request and response shapes are unchanged, so an integration built against them during the limited release needs no update.

POST /api/v1/appointments takes billableItemIds, the items the appointment is invoiced for, as returned by GET /api/v1/billable-items. Order matters: the first identifier becomes the appointment's service. Send none and the appointment is not invoiced.

Appointments: the invoiced billable items can be replaced​

PATCH /api/v1/appointments/{id} takes billableItemIds as the full set the appointment is invoiced for, replacing whatever is there. Omit it to leave the invoice untouched, or send an empty array to clear the billable items, which leaves the invoice with a zero total rather than deleting it. Anything else on the invoice, such as a session-pack session or a card surcharge, stays as it is.

The page parameter no longer exists on any list endpoint. Every list is paged with cursor. This is 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 beginning. pageSize is unchanged and still sets how many records a page holds. Paging by cursor is forward-only, so there is no page number to jump to and no total to divide.

Before:

GET /api/v1/invoices?page=3&pageSize=25

After:

GET /api/v1/invoices?cursor=CURSOR_FROM_PREVIOUS_RESPONSE&pageSize=25

POST /api/v1/group-appointments/{appointmentId}/participants adds a client to an existing group booking.

POST /api/v1/group-appointments creates a group appointment.

DELETE /api/v1/group-appointments/{appointmentId}/participants/{clientId} removes one participant from a group booking, leaving the other participants untouched.

On GET /api/v1/resource-items and GET /api/v1/resource-items/{id}, the single locationId field is gone. A resource item now returns locations, a list of the locations it is available at, each with 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 resourceItem.locations and match on the entry you need instead of comparing locationId. The locationId filter on the list endpoint is unchanged and now matches an item at any of its locations.

Before:

"locationId": 3

After:

"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" }]
  }
]

On PATCH /api/v1/appointments/{id} and PATCH /api/v1/group-appointments/{appointmentId}/participants/{clientId}, scheduleReminder is rejected once the appointment's start time has passed, and while the attendance state is anything other than Pending or Confirmed unless a reminder has already been sent. Setting it to true also requires a client who can receive reminders. Omit the property in those cases. The rules now match the ones the Zanda app applies.

Invoices can be created against a deactivated practitioner​

POST /api/v1/invoices no longer rejects an invoice whose practitioner has since been deactivated, which 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 some practices; this is now fixed.

POST /api/v1/client-profiles/clients and PATCH /api/v1/client-profiles/clients/{id} are out of limited release and enabled for all practices. Request and response shapes are unchanged, so an integration 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 classification, category or status, is rejected with 400. Read the current options from the matching reference-data endpoint.

On GET /api/v1/referrals and GET /api/v1/referrals/{id}, the referrerType field has changed from a plain text name to an object with an id, a name, and a link to the matching referrer type. This is a breaking change to the referral response.

If you currently read the referrer type's name, change referral.referrerType to referral.referrerType.name. You can now also use referral.referrerType.id to fetch it from GET /api/v1/referrer-types/{id}, or match it against the GET /api/v1/referrer-types list. As before, referrerType is null when a referrer has no type set.

Before:

"referrerType": "General Practitioner"

After:

"referrerType": {
  "id": 42,
  "name": "General Practitioner",
  "links": [{ "href": "/api/v1/referrer-types/42", "rel": "self", "method": "GET" }]
}

Note and form templates​

• 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 participant'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; fetch a single note to read its answers.

Payments can be created, updated and deleted by every practice​

POST /api/v1/payments, PATCH /api/v1/payments/{id} and DELETE /api/v1/payments/{id} are out of limited release and enabled for all practices. Nothing about them changed on the way out, so an integration built against them during the limited release needs no update.