Skip to main content

​
Version in the URL

Every Spirii REST API is versioned in the URL path, and each API is versioned independently — a major bump on one does not move the others. 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.
The Energy Management API is the exception. It is asynchronous, and its channel addresses are provisioned per actor during onboarding, so there is no path for you to read a version from. Its version is declared in the AsyncAPI document instead.

​
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.