38 posts tagged with "Added"

Created and modified dates on payments​

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.

Write operations are now linked from the responses you already fetch​

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.

Beta endpoints are labelled​

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.

Appointments can be invoiced for billable items​

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.

Group appointments: add a participant​

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

Group appointments can be created​

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

Group appointments: remove a participant​

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

Referrals: referrerType is now an object​

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.

Group appointments: edit one participant​

PATCH /api/v1/group-appointments/{appointmentId}/participants/{clientId} updates a single participant's appointment within a group booking, leaving the other participants untouched.

Group appointments can be updated​

PATCH /api/v1/group-appointments/{id} edits a group appointment.

Notes​

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.

Group appointments link to each participant's appointment​

Each client in a group appointment now carries a link to its own participant appointment, so you can navigate from the group to an individual booking without building the URL yourself.

Appointments can be created​

POST /api/v1/appointments creates a single-client appointment.

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.

Forms​

GET /api/v1/forms and GET /api/v1/forms/{id} list and fetch completed client forms.

Appointments can be updated​

PATCH /api/v1/appointments/{id} edits an existing appointment.

Group appointments: fetch one participant​

GET /api/v1/group-appointments/{appointmentId}/participants/{clientId} returns a single participant's appointment within a group booking.

Invoices: an insurer cannot be added twice​

Adding the same insurer to an invoice more than once is now rejected with 400 instead of creating a second identical entry.

Invoices can be created​

POST /api/v1/invoices creates an invoice.

Saleable categories, relationship types and referrer types​

Three more reference lists, each with a list and a by-id endpoint: GET /api/v1/saleable-categories, GET /api/v1/relationship-types and GET /api/v1/referrer-types.

Appointments: cancellationReason is now an object​

On GET /api/v1/appointments and GET /api/v1/appointments/{id}, cancellationReason has changed from a plain text name to an object with an id, a name and a link to the matching reason. This is a breaking change to the appointment response.

If you read the reason's text, change appointment.cancellationReason to appointment.cancellationReason.name. You can now also match it against GET /api/v1/cancellation-reasons. As before, it is null when the appointment was not cancelled.

Before:

"cancellationReason": "Client unwell"

After:

"cancellationReason": {
  "id": 7,
  "name": "Client unwell",
  "links": [{ "href": "/api/v1/cancellation-reasons/7", "rel": "self", "method": "GET" }]
}

Cancellation reasons and appointment flags​

GET /api/v1/cancellation-reasons and GET /api/v1/appointment-flags list the practice's cancellation reasons and appointment flags, each with a by-id endpoint.

Paging by page is deprecated​

The sortable list endpoints now return Deprecation, Sunset and Link headers when you page with page. It keeps working until the sunset date the header carries, and the Link header points at the pagination documentation. Move to cursor before then.

Cursor pagination on the sortable list endpoints​

Pass the cursor value returned by the previous response to fetch the next page; omit it to start from the beginning. Paging this way is forward-only, so there is no previous-page link, and it stays fast on a large practice however deep you go.

Pronouns​

GET /api/v1/pronouns and GET /api/v1/pronouns/{id} list and fetch the practice's pronoun options, and a client profile now embeds the client's pronouns as an object with an id, a name and a link.

Client classifications​

GET /api/v1/client-classifications and GET /api/v1/client-classifications/{id} list and fetch the practice's client classifications, and a client profile now embeds clientClassifications, a list of the classifications assigned to the client, each with an id, a name and a link.

Custom profile fields​

GET /api/v1/custom-profile-fields and GET /api/v1/custom-profile-fields/{id} list the custom fields a practice has defined for its client profiles, and fetch one by id.

Marketing sources​

GET /api/v1/marketing-sources and GET /api/v1/marketing-sources/{id} list the practice's marketing sources, and fetch one by id.

Rate limit headers on successful responses​

Every successful response now carries X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset, so you can pace a batch of requests instead of discovering the limit by being refused.

Client profiles carry their active insurers​

GET /api/v1/client-profiles/{id} now returns the client's active insurers, so you no longer need a second call to work out who covers them.

Invoices: each payment link carries its amount​

An entry in an invoice's invoicePayments now includes the amount applied to that invoice, so a payment split across several invoices no longer has to be reconciled by hand.

Invoices can be updated​

PATCH /api/v1/invoices/{id} updates an existing invoice.

Sorting on client profiles​

You can now sort GET /api/v1/client-profiles by lastName, name, dateAdded, clientNumber or id. Every list endpoint now sorts.

Every record reports when it last changed​

Each of the nine resources now returns a lastModified timestamp, and every list endpoint can be filtered by modifiedSince. Together they let you poll for what has changed since your last call instead of reading everything each time.

Client profiles carry their profile roles​

A client profile now reports the roles it holds in the practice, and you can filter GET /api/v1/client-profiles by profileRoles to list only the profiles holding a given role.

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.

Sorting on payments​

You can now sort GET /api/v1/payments by dateReceived, total or id.

Sorting on referrals​

You can now sort GET /api/v1/referrals by name, dateFrom, dateTo or id.

Client profiles: the custom category is an embedded object​

customCategory now carries the category's id and name and a link to it, the same shape customStatus was given earlier this month.

Sorting on appointments​

You can now sort GET /api/v1/appointments by dateCreated, dateFrom, dateTo, id or flag, with the sort parameter. Add :desc to reverse a field, and separate several with commas, as in sort=dateFrom:desc,id.

Sorting on invoices​

You can now sort GET /api/v1/invoices by invoiceDate, invoiceDueDate, totalCharges or id.

Payments carry their location​

A payment response now names the location it was taken at.

Filtering on referrals​

You can now filter GET /api/v1/referrals by isActive, clientId, startDateFrom, startDateTo, endDateFrom and endDateTo.

Appointments and payments can be filtered by isActive​

Pass isActive=true to leave out records the practice has since deactivated, or isActive=false to see only those. The other list endpoints already had it.

Payment methods​

GET /api/v1/payment-methods and GET /api/v1/payment-methods/{id} list the practice's payment methods and fetch one by id.

Filtering on invoices​

You can now filter GET /api/v1/invoices by isActive, isPaid, clientId, practitionerId, locationId, invoiceDateFrom, invoiceDateTo, dueDateFrom and dueDateTo.

Filtering on appointments​

You can now filter GET /api/v1/appointments by dateFrom, dateTo, clientId, practitionerId and locationId.

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.

The Zanda Public API is available​

The API gives you read access to a practice's scheduling and billing data, versioned under /api/v1. Nine resources are available, each as a list and as a single record: appointments, billable-items, client-profiles, insurers, invoices, locations, payments, practitioners and referrals.

Authenticate with the practice's API key in an X-API-KEY header. Lists are paged with page and pageSize, which returns 10 records by default and 25 at most, and every response carries links to its related records so you do not have to build the next URL yourself. Requests are rate limited.

Reference documentation for every endpoint is published with the API.