Breaking Changes Policy
As the Logistics Plus 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, Logistics Plus 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 Logistics Plus. 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
Please use non-restrictive validators and parsers to ensure that your system is designed to manage non-breaking changes without extra effort on your side.
The following is a list of change 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.