Skip to content
Last updated

Breaking changes policy

Solaris continuously improves its platform. While we strive to maintain backward compatibility, some updates may alter the API behavior. This policy defines how we classify changes and when we notify you.

Breaking changes

A breaking change is any update that requires you to modify your code to prevent your integration from failing.

Solaris will always announce breaking changes in advance, providing a deprecation period to give you sufficient time to update your implementation.

Examples of breaking changes:

  • Removal: Removing a resource, endpoint, or parameter.
  • Renaming: Changing the name of a parameter or endpoint.
  • Type Change: Changing a parameter's data type (e.g., string to integer).
  • Stricter Validation: Making an optional parameter mandatory or adding new validation constraints.
  • Reduced Scope: Removing values from an existing enumeration.

Non-breaking changes

A non-breaking change is an update that is backward-compatible and should not cause errors in a correctly implemented client.

Solaris does not provide advance notice for non-breaking changes. Your application must be built to handle these updates dynamically.

Examples of non-breaking changes:

  • Additions: Adding new endpoints, optional request parameters, or new fields to a response body.
  • Re-ordering: Changing the order of fields in a JSON response.
  • Relaxed Validation: Making a mandatory parameter optional or loosening validation constraints.
  • Expanded Scope: Adding new values to an existing enumeration.
Best Practice: Tolerant Reading

To ensure your integration remains stable during non-breaking changes, follow the Tolerant Reader pattern:

  1. Ignore unknown fields: Your JSON parser should not throw an error if it encounters a new, unrecognized field in a response.
  2. Handle new enums: Set a default fallback behavior if you receive an enumeration value your system does not yet recognize.
Previous page
Next page