Notification periods

In regard to changes Semansys Technologies BV will strive to adhere to the following notification periods per type of change. Due to our versioning strategy at resource level this API has the possibility to run multiple versions of the same resource at one time. This allows for a window in which both the old and new version are available. Allowing for a gradual move to the new version.

Type of change	Notification period	Support period (old version)
Non breaking change.	Two weeks.	No new version.
Breaking change.	Two weeks.	6 months.
Critical.	Due to the nature of these changes we might not be able to follow the normal procedure for change management.	Depends on the severity of the issue.

API change definitions

Non-Breaking Changes

A non-breaking change is defined as any modification to the APIs that maintains backward compatibility and does not cause failures in applications that consume those APIs.

Examples of non-breaking changes include:

• Adding new optional fields to existing resources

• Introducing new endpoints

• Adding new operations (GET/PUT/POST/PATCH/DELETE)

• Adding new optional parameters to existing endpoints

• Introducing new versions of a resource

Breaking Changes

A breaking change is defined as any modification to an API that could potentially cause failures in applications that consume that API.

Examples of breaking changes include:

• Modifying existing JSON elements (changing names, datatypes, patterns, min/max length requirements, etc.)

• Removing JSON elements, endpoints, operations, or parameters

• Adding new required JSON elements to existing structures

• Adding new required parameters to existing endpoints

• Passing the obsoleteDate of a version for a resource