Versioning and changes
How the REST API is versioned, and what to expect as it evolves.
The current version
The current API is v1. All endpoints live under the /api path on your intranet's API domain, as shown throughout the API reference.
What counts as a compatible change
We aim to make only backward-compatible changes to v1. The following are considered non-breaking, and can be added at any time, so your integration should tolerate them:
- New endpoints.
- New optional request parameters or body fields.
- New fields in a response body.
- New values in an existing enumeration.
To stay compatible, write clients that ignore fields they do not recognise and do not assume a response contains only the fields you use today.
What counts as a breaking change
Changes that could break an existing integration — removing or renaming a field, changing a field's type, or removing an endpoint — are avoided within v1. Where such a change is unavoidable, it would be introduced in a way that does not disturb existing v1 clients.
Staying informed
Track additions and changes on the Changelog. If you depend on a specific endpoint's behaviour, verify it against a live call after any update.