Overview
As an infrastructure provider to some of the leading healthcare software providers, Corti is as focused on maintaining long-term stability as on delivering rapid improvements and innovative functionalities. The following guidelines serve to communicate how we approach changes, what we consider breaking changes and how we communicate those.We will list deprecations and upcoming breaking changes on Upcoming Changes
Response and Schema Changes
When a change to a response or API schema is additive, i.e. adding new optional fields to a response or a new optional request property, we do not consider this a breaking change.When integrating with the Corti API, your API client is thus required to ignore fields that the client does not recognize and to not have strict typing checks for API responses.
Breaking changes
- The change removes an existing response field.
- The change modifies the structure of the existing responses.
- The change adds a new required request property.
- The change turns an optional into a required property.
Parameter Changes
When a change is adding an optional parameter, we do not consider this a breaking change.Breaking changes
- The change turns an optional parameter into a required parameter.
- The change adds a required parameter.
- The change alters the type or format of the parameter.
Endpoint and Path Changes
Communication of Changes
For non-breaking changes, we do not pro-actively communicate changes but will at irregular intervals post key changes in the Release Notes and Change Log. For breaking changes, we will do three things:1
Communicate the upcoming change in response headers for the affected endpoint
2
The header will reference a URL where we communicate the change here on docs.corti.ai
3
A message will be shown when signed into Corti Console
When relevant, we will temporarily accept or return both old and new properties until deprecating the old one.