Versioning - Spirii

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.

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.