API Changes
This section gives a list of changes to Enate's APIs from version 2024.1 and above.
What is a breaking change?
With each release of Enate (both major and minor), the changes to Enate's APIs may also include breaking changes. Examples of breaking changes are:
Changes to the URL or fundamental request/response associated with a resource
Removal, rename, or change to the type of a declared property
Removal or rename of APIs or API parameters
Addition of a required request header
Addition of a required API parameter
Examples of changes which are NOT considered breaking changes and are outside the scope of this document are:
Addition of properties that are nullable or have a default value
Addition of an optional API parameter
Addition of a member to an enumeration
Removal, rename, or change to the type of an open extension
Removal, rename, or change to the type of an annotation
Introduction of paging to existing collections
Changes to error codes
Changes to the order of properties
Changes to the length or format of opaque strings, such as resource IDs
Choosing the version you call
Enate keeps earlier API versions available so that an existing integration keeps working when a new version is released. You choose the version with the api-version query string parameter:
Latest stable version of the Operational API
3 in the July 2026 Feature Wave
Latest stable version of the Configuration API
3 in the July 2026 Feature Wave
If you leave api-version off a request
Enate applies the latest stable version for that API rather than rejecting the request
Versions numbered above the latest stable one
Previews of a future contract. Swagger marks them as preview, and they can still change before release
Where to see the versions your instance exposes
Swagger. Enate doesn't return the available versions in a response header
Send api-version explicitly on every request. The latest stable version moves on when a feature wave makes a new version stable, so an unversioned request quietly starts resolving to the new contract. Leaving the parameter off puts Enate in charge of when your integration changes version, rather than you.
Don't build a production integration against a preview version. A preview exists so you can see what's coming and give feedback, and the contract can change before it becomes stable.
What a released version guarantees
Once a version has been released, the whole of it is frozen. Endpoints, request and response shapes, property names and types, and the enumeration values behind them all stay as they are in that version for as long as the version is available. New work goes into the newest version instead, which is why everything in the second list above is safe: an addition can't reach an integration that's pinned to an older version.
That's what makes pinning worth doing. An integration built and tested against version 3 keeps getting version 3's contract, and you decide when to move.
There's one consequence worth planning for. Enate holds one set of values internally, and where the version you called has no member for a value Enate needs to return, the request is rejected with a 400 rather than returning a number the version doesn't define. The API Enums page covers what that response looks like and what to do about it:
API EnumsRate limiting
Enate's APIs are rate limited. An integration that exceeds the limit receives HTTP 429 Too Many Requests, with no Retry-After header, and needs to back off and retry. This isn't a change to any request or response contract, but it does change how an integration written against an earlier release behaves under load, so review the pacing of anything that sends requests in bulk. The limits and the recommended client behaviour are on the APIs page:
API Changes Documents
See the following documents for details of all the API changes, including breaking API changes.
July 2026 Feature Wave API Changes
Version 2 - Version 3 Configuration API Change Document
Version 2 - Version 3 Operational API Changes
April 2026 Feature Wave API Change Documents
Version 1 Configuration - Version 2 Configuration API Changes
Version 1 Operational - Version 2 Operational API Changes
November 2025 Feature Wave Change Document
Version 1 Configuration API
Version 1 Operational API
2024.1 Legacy API
v2024.1
How to use the API Changes document
Recommendations for how best to use the breaking changes document information to highlight where you may need to make changes to your code which involves Enate APIs.
Recommendation for best use of API breaking changes documentation is as follows:
Read through the breaking changes information for APIs.
Upon finding reference to an API which you currently use and which has changed, go to your Swagger environment for the quickest way to view the overall impact and new API content definition. Your Swagger environment should always be your go-to place for the definitive explanation of the current API structure. See the Swagger explanation section for more info.
Last updated
Was this helpful?