Skip to content

Versioning

The API uses versioning directly in the URL:

http
GET /api/v1/Client/Simple
  • Future major versions may run in parallel (e.g. /api/v1/... and /api/v2/...)

Compatibility

Within a single major version (e.g. v1) we commit to not breaking backward compatibility:

  • New optional parameters may be added
  • New fields in responses may be added
  • Existing response fields are not removed or changed in type

Recommendations

  • Keep the API version in configuration, not hardcoded in the URL.
  • When transitioning to a new major version, plan a transition period.

Deprecated endpoints

  • Older endpoints may be marked as deprecated in the documentation and in Swagger UI before being fully removed.
  • Before an endpoint is removed, a transition period will be available where both the old and new version will work (where possible), to ease migration.
  • An endpoint will only be removed when necessary (e.g. security reasons, significant performance improvements) and always with sufficient advance notice.

Practical recommendations

  • Monitor announcements on the website or by email
  • Prepare a migration plan when a new version is released
  • Do not delay upgrading to a newer version