Versioning

Code written against /api/v1 keeps working: v1 only gains things. Within v1, changes are additive only: new optional fields, new endpoints, new query parameters. Write your client to ignore fields it does not know.

A breaking change ships under a new prefix (/api/v2) instead of changing v1 in place. Breaking means a removed or renamed field, a changed field type or changed error semantics. A v2 does not deprecate v1: existing integrations keep working.

Every change to the contract is listed in the Changelog.

What you can rely onCopy Anchor Link

• Every documented field stays in v1 with its name and type.
• code in an error body is stable. message is not; see Errors.
• Query parameters are camelCase (perPage, fromDate, serviceIds). Every list answers with the data envelope and every error is {code, message}.

Before the first production releaseCopy Anchor Link

Before the first release two changes went into v1 in place instead of a v2:

• On 2026-08-07 appliedVoucher was renamed to appliedDiscountCode on the order detail response.
• On 2026-09-28 v1 was normalised: camelCase query parameters, the data envelope on every list, {code, message} on every error.