Demand API Versioning strategy

This section provides an overview of the Demand API versioning strategy, offering practical guidance on integration and ensuring efficient usage within the prescribed limits.

Version strategy

At Demand API, we strive to make our versioning strategy as predictable and straightforward as possible for developers.

We follow a clear, cadence-based approach that ensures partners can easily plan their integrations and remain confident in the long-term stability of the API.

Each new version reflects changes in functionality, and we carefully manage backward compatibility with the goal of minimising disruption.

Breaking vs non-breaking changes

Changes	Description	Stable version impact	Beta version impact
Breaking changes	Introducing new functionality or changes that affect existing functionality.	This always results in a new Minor stable version¹ (e.g., v3.1, v3.2). Developers must adapt integrations to accommodate these changes. Comprehensive migration guides and documentation are provided.	It may also be introduced a Beta version (e.g., v3.2 Beta) restricted to certain partners, for testing before becoming stable.
Non-breaking changes	Bug fixes, feature enhancements, small field additions, or other improvements that do not affect existing functionality.	These are added to the most recent statble version of the API or in the next incremental release, with minimal disruption to existing integrations.	Non-breaking changes may also appear in the Beta version if related to ongoing testing or refinements.

This approach ensures that existing applications continue functioning without disruption, while developers can access new features when appropriate.

1 Please note that the Demand API does not adhere to a strict semantic versioning schema, as it does not have distinct major or patch releases. It also includes a Beta version for experimental purposes.

Why this approach?

Annual major release in Autumn - Makes roadmapping easier and allows partners to plan upgrades efficiently.
Upgrade requirements - Partners must upgrade at least every two years, though it is possible to skip a year if needed.
Regular minor updates - Backward-compatible updates throughout the year ensure the API remains up-to-date.
Confidence for tech teams- A predictable, stable API helps partners’ teams plan ahead and deliver integrations with confidence.

Release cadence

We adhere to the following release schedule to keep our API predictable and manageable:


Breaking changes release	One new minor stable release per year that includes breaking changes and is compatible with previous versions.	This release is scheduled annually (every Autumn), providing developers with ample notice for significant updates. Previews of new functionality may be available earlier in the Beta version.
Incremental releases	Following the Continuous delivery (CD) approach: Non-breaking changes are continuously rolled out throughout the year.	Developers receive regular updates through this Developers portal (Changelog, News, etc.) with minimal disruptions.

This cadence makes it easier for developers to plan their updates and ensures that we can evolve the API without introducing unexpected or disruptive changes.

Versioning cycle

Our versioning cycle ensures that developers are given sufficient time to adapt to changes and migrate safely:


General availability (GA)	We actively support two minor stable versions of the API and one Beta version for general use or testing.
Maintenance mode	After a version reaches its end of life, it enters maintenance mode for 12 additional months. During this period, the version is still available for use, but no new features are added, and only critical bug fixes or security patches are applied.
Deprecation (End of support)	After the 12-month maintenance window, the version is deprecated, and no further updates or support is provided. Developers are strongly encouraged to migrate to the newer supported versions during this period.

versioning in numbers

Backward compatibility

Backward compatibility is a key principle in our API strategy. We make every effort to ensure that new versions of the Demand API are compatible with existing integrations.

Non-breaking changes - Always introduced without disrupting existing functionality..
Breaking changes - Introduced in full releases, with migration paths, documentation, and ample notice for developers to adapt.

We encourage developers to follow our upgrade guidelines and migrate to newer versions promptly, ensuring both security and stability.

Upgrade guidelines

To upgrade smoothly to a new Demand API version:

Steps
☑ Review Changelog	Always read the latest technical enhancements for any new version to understand the changes, particularly when upgrading between breaking-changes versions.
☑ Check any deprecation news	Be aware of any upcoming deprecations for the version you are currently using, and plan your migration accordingly.
☑ Read the Migration guidelines	Find all technical details that you need for your migration.
☑ Test in Sandbox environment	Before rolling out any updates to your live environment, ensure you test the new version in a sandbox environment. You can use this portal "Try out" option.
☑ Monitor	After upgrading, monitor your application for any potential issues or deprecations that may arise.

If you have any questions or need assistance with version upgrades, please refer to our support documentation or reach out to your Account manager for further guidance.

Start planning your upgrade today by reviewing the Changelog and Migration Guide linked above.

Curious to know more?

Refer to Changelog to see latest changes and versions.
Explore the Accommodations migration guide for instructions on how to migrate from Demand API previous versions.