Skip to main content

Change policy

In the digital world, where technologies and requirements are ever-evolving, it's crucial for services to adapt and update continually. An essential component of this process is how changes are communicated and rolled out to the users. Our API is no different. As we strive to provide the best possible experience for our users, we are introducing a structured change policy for our API to ensure transparency, predictability, and stability for our user base.

Non-Breaking Changes

  • Definition: Non-breaking changes are those modifications that don't affect the existing functionality of the API. These might include adding new fields to the responses or other enhancements that don't disrupt the current user experience.

  • Policy: Given their non-disruptive nature, non-breaking changes will be rolled out immediately, without prior notice to the users. We believe this approach will allow users to benefit from enhancements swiftly, without any adverse effects on their current setups.

Breaking Changes

Breaking changes are those that can potentially disrupt or alter the way users interact with our API. We understand the potential challenges these can pose. To address this, we've categorized breaking changes into two: Non-critical and Critical.

Non-Critical Breaking Changes

  • Definition: A non-critical change might involve modifications like removing a field from the response. While these changes may necessitate some adjustments on the user's end, they don't alter the core concept of the product or the overall representation of data.

  • Policy: For non-critical breaking changes, we will provide a notification to our users 30 days in advance of the deprecation. After this period, the affected fields or endpoints can be removed or modified anytime, but it's not mandated that the change will be deployed precisely on that day.

Critical Breaking Changes

  • Definition: Critical changes are those that have a more profound impact on the functioning or representation of the API. Such changes could redefine the way users have been interacting with our service.

  • Policy: Recognizing the significance of such changes, we will notify our users 60 days in advance of the deprecation. Post this window, the impacted fields or endpoints can be removed or modified at any time. Again, this doesn't imply a change on that exact day but indicates the start of the period during which we can deploy the change.