Versioning

Changing an API is always difficult as soon as it is published and consumed by even one user. As we develop more features and add new products, our API needs to evolve in the process as well. We use a versioning approach as this allows us to continue adding features to the SiteHost API, while also ensuring old versions work as expected.

API versioning at SiteHost

Generally, we only make backward compatible changes to the published API version to ensure that your current integration continues to work for the foreseeable future. We consider the following as backward compatible changes:

• Adding new endpoints.
• Adding new optional parameters to existing endpoints.
• Adding new properties to the response body of existing endpoints.
• Adding new accepted values for parameters of existing endpoints that accept a list of defined values.
• Changing the order of properties in the response body of existing endpoints.

However, when we must introduce non-backward compatible changes to the API, we will release a new version while ensuring the old versions continue to work so that you can upgrade to the latest version when you are ready. The changes we considered as non-backward compatible are:

• Adding new required parameters to existing endpoints.
• Removing parameters from existing endpoints.
• Removing properties from existing endpoints.
• Changing or removing the accepted values for parameters of existing endpoints that accept a list of defined values.
• Deprecating existing endpoints.

In some rare cases, underlying infrastructure changes might require you to alter how you integrate or consume some endpoints even though they have not been changed. We aim to avoid this as much as possible and make you aware ahead of time when such a problem arises.