12 posts tagged with "Fixed"

Appointment resource assignment​

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.

Invoices: cursor paging could still time out​

Paging through GET /api/v1/invoices with cursor could still fail rather than return a page for some practices; this is now fixed.

Appointments: an appointment with no client returned 500​

A client appointment with no client attached made GET /api/v1/appointments fail rather than return the page. Those appointments are now returned normally.

Client profiles: the first page could time out​

GET /api/v1/client-profiles could take long enough to fail with a server error rather than return its first page, on practices with many clients.

Resource items​

GET /api/v1/resource-items and GET /api/v1/resource-items/{id} list and fetch the practice's bookable resources.

Invoices: paging by cursor was slow past the first page​

Following the cursor on GET /api/v1/invoices could take long enough to time out on a large practice.

Invoices: the embedded referral linked to the wrong record​

The referral embedded on an invoice carried the referrer's id and self link rather than the referral's own, so following the link resolved to a different resource.

Referrals: startDate and endDate are dates, not date-times​

On GET /api/v1/referrals and GET /api/v1/referrals/{id}, the two referral dates are returned as plain dates rather than as timestamps at midnight. The matching filters, startDateFrom, startDateTo, endDateFrom and endDateTo, accept a plain date too. This is a breaking change if you parse either field as a date-time.

A referral begins and ends on a day, not at an instant, so the time component was always zero and the timezone it implied was misleading. Parse both fields as dates, and send dates when you filter. Both remain null when the referral has no such date set.

Before:

"startDate": "2026-06-15T00:00:00Z"

After:

"startDate": "2026-06-15"

Invoices: deep pages timed out​

Requesting a high page number from GET /api/v1/invoices could take long enough to fail with a server error rather than return.

Page size now ranges from 1 to 100​

pageSize accepts anything from 1 to 100, where it previously accepted 5 to 25. The default is unchanged at 10 records.

Referrals: client and referrer details were swapped​

GET /api/v1/referrals returned the client's details in the referrer fields and the referrer's in the client fields.

Filter by date in the practice's time zone​

Send an X-Time-Zone header with an IANA time zone name, such as Australia/Sydney, and date filters are interpreted in that zone rather than in UTC. An unknown name is rejected. Without the header, behaviour is unchanged.

Sex, gender and gender identity​

GET /api/v1/sexes, GET /api/v1/genders and GET /api/v1/gender-identities list the values a practice can record, each with a by-id endpoint.

Client profiles carry the client's identity​

A client profile response now includes the client's identity details, drawn from the same values those three endpoints list.

Sorting by date sorted incorrectly​

A sort on a date field ordered records by the text of the date rather than by the date itself, so pages came back in the wrong order.

Payments: paidBy was always null​

Every payment returned paidBy as null, whoever had made the payment. It now names them.

Filtering on client profiles​

You can now filter GET /api/v1/client-profiles by isActive, isArchived, dateAddedFrom, dateAddedTo, primaryPractitionerId, customStatusId and customCategoryId.

Filtering on practitioners​

You can now filter GET /api/v1/practitioners by isActive, profession, jobTitle and emailAddress.

Filtering on payments​

You can now filter GET /api/v1/payments by clientId, clientNumber, methodId, receivedAfter, receivedBefore, minAmount and maxAmount.

Paging returned records more than once​

Records could appear on two pages, or on none, because list results had no stable order when two records shared a sort value. Every list endpoint now orders deterministically.

Billable items: pricing is now correct​

GET /api/v1/billable-items could return a price that did not match the one the practice had set.