> ## Documentation Index
> Fetch the complete documentation index at: https://help.lobyco.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Lobyco API Breaking Change Policy

> What Lobyco treats as a breaking change, and the notice period you can rely on.

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.

<Info>
  **Important**

  Lobyco 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.
</Info>

## 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.

<Warning>
  While non-breaking changes do not require immediate updates,\
  **we recommend designing clients to handle them gracefully**,\
  especially in dynamic response structures.
</Warning>

## 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:
  * The [Breaking Changes timeline](/integration/breaking-changes) on this site and its [RSS feed](/integration/breaking-changes/rss.xml)
  * Email notifications to customers
* Urgent changes due to legal or security concerns may be rolled out immediately, with notification following soon after.