Skip to main content
At Lobyco, we continuously develop our products, this means also changing our APIs to deliver better functionality, performance, and security. As part of this evolution, changes are periodically introduced—some of which may require your attention as they can affect your integration. We will make reasonable efforts to notify you in advance of any breaking changes and provide sufficient time to adapt. However, there are scenarios (e.g., critical security issues or legal compliance) where prior notice may not be feasible.
ImportantLobyco may introduce changes without prior notice if the change is non-breaking or if the change addresses urgent issues such as security vulnerabilities, legal requirements, or critical bugs.

​
Definition

​
What is a Breaking Change?

A breaking change is any change that requires modification to your application to avoid integration issues or service disruption. Examples include:
  • Removal of an existing parameter, request field, or response field.
  • Changes to permission scopes or access definitions.
  • Addition of a required parameter or field with no default value.
  • Changes to endpoint behavior or functionality.
    e.g., an endpoint that previously archived an object now deletes it.
  • Modifications to validation rules.
  • Introduction of new mandatory validations.
  • Changes in data formats (e.g., data type from string to object).
  • Throttling policy updates or reduced rate limits.

​
What is a Non-Breaking Change?

A non-breaking change is one that your integration can adapt to without mandatory updates, and it will not cause service failure. Examples include:
  • Addition of new optional fields or parameters.
  • New fields in responses.
  • Addition of new endpoints or methods.
  • New validation rules that apply only to new fields.
  • Changes to response order (fields, arrays) that do not affect structure.
  • Field or method deprecation without removal.
  • New enum values in optional parameters.
While non-breaking changes do not require immediate updates,
we recommend designing clients to handle them gracefully,
especially in dynamic response structures.

​
Notification Policy

When a breaking change is planned:
  • We will maintain two versions of the affected API for a minimum of 6 months, when feasible.
  • We will provide notice through:
  • Urgent changes due to legal or security concerns may be rolled out immediately, with notification following soon after.
Last modified on August 13, 2026