API versioning

Never stop improving

API Versioning Strategy

We’ve established a versioning strategy to manage updates to our API, ensuring smooth transitions and backward compatibility for our partners. When a new version is released, you can continue using the current version or migrate to the updated version at your convenience.

---

Deprecation and Upcoming Changes

• Deprecated Methods: Some methods are marked as deprecated due to limitations in our interactive documentation. These methods are not actually deprecated but are planned for future release. You can ignore these parameters as they relate to features outside the scope of your current integration.

• Continuous Updates: We are constantly improving and adding new functionalities to the API. As long as updates are backward-compatible and non-breaking, they will be incorporated into the current version. If any breaking changes are needed, a new version will be released. Please note that syntax for upcoming features may change before release.

---

Release and Deprecation Process

• New Versions: New API versions are released as needed. Any breaking changes will trigger a version increment. All endpoints will be updated to the latest version when a new release occurs.

• Notifications: Partners will be notified of version releases, including new features and any breaking changes.

• Deprecation Period: Once an API version is deprecated, partners will have a minimum of 18 months to update their systems. After this period, requests to deprecated versions may result in a 400 Bad Request response.

---

Release Criteria

• Backward-Compatible Changes: Some changes do not require a version increment and are fully backward-compatible. These include:

  • Introduction of new API endpoints.

  • Addition of non-required properties to request/response schemas.

  • Addition of new HTTP methods (POST, GET, PUT, PATCH, DELETE).

  • Addition of new key values in existing fields (without changing operational logic).

  • Unexpected HTTP redirects (301, 302) may be handled as part of normal operations.

• Breaking Changes: Any changes that break compatibility with existing implementations will result in a version increment. These include:

  • Addition or removal of required properties in request/response schemas.

  • Change in data type or format of fields (e.g., changing date formats).

  • Alteration or removal of HTTP status codes in responses.

  • Modifying the Content-Type on existing endpoints.

  • Modification or removal of field key values in a set.

  • Changes to the operationId of an endpoint.