> ## Documentation Index
> Fetch the complete documentation index at: https://docs.spirii.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Versioning

> The Spirii API follows Semantic Versioning, ensuring a clear and predictable versioning structure

## Version in the URL

Every Spirii API is versioned in the URL path, and each one is versioned independently — a major bump on one API does not move the others.

| API         | Current version | Example                                                   |
| ----------- | --------------- | --------------------------------------------------------- |
| Spirii API  | **v2**          | `https://api.spirii.com/v2/locations`                     |
| eMSP API    | **v1**          | `https://api.spirii.com/emsp/v1/locations`                |
| Billing API | **v1**          | `https://api.spirii.com/reimbursement/v1/expense-reports` |

Where the version sits differs by API. The Spirii API puts it first, directly after the host. The eMSP and Billing APIs put it after their path prefix (`/emsp/`, `/reimbursement/`). Read the version from the endpoint's own path rather than assuming a position.

## What counts as a breaking change

The following changes are considered breaking and trigger a major version bump:

* Removing or renaming a field on a response object.
* Removing an endpoint or HTTP method.
* Changing the type of an existing field.
* Tightening validation on request bodies in a way that rejects previously valid input.

The following are **not** breaking and may ship in any minor version:

* Adding new endpoints.
* Adding new optional request parameters.
* Adding new fields to response objects.
* Adding new enum values to existing fields.

<Tip>
  When parsing responses, treat unknown fields as ignorable and unknown enum values as a generic fallback. This keeps your integration forward-compatible with minor releases.
</Tip>