Breaking Changes Policy

Abstract

As the Transporeon platform evolves, we add new functionality and changes to our interfaces every month.

Changes that are considered non-breaking are released without prior notice. If a change is considered otherwise as breaking, Transporeon will make a reasonable effort to separate it to a new interface version and/or notify customers in advance to give sufficient time to adapt.

Note, we do our best to avoid any change that can be considered as breaking to keep efforts for customers low.

Breaking Change

A breaking change that may require you to adapt your system to continue using integration with Transporeon. See following examples:

  • renaming fields of objects or resource names and paths

  • removing fields of inbound or outbound messages or changing their data type

  • adding mandatory fields to an existing object without default values

  • changing logic of an existing endpoint without backwards-compatibility

Non-Breaking Change

Following is a list of changes examples that are considered as non-breaking:

  • introducing new objects and resources, used in new inbound and outbound messages

  • adding new methods for existing resources

  • adding logic to an existing resource, without changing behavior

  • adding to outbound exports mandatory fields with default values

  • adding new fields, measurements, and parameters in outbound messages

  • introducing optional headers, fields, and parameters in inbound messages

  • changing sizes of lists in outbound messages

  • introduce new error messages or changing their text in responses.

Â