Versioning Temenos APIs

To avoid breakages for existing developers, Temenos creates a new API version whenever we make a backwards incompatible change to a released product. That means you can continue to use the previous API version, or update to the API version, without service issues. If we’re working on a beta or unreleased APIs, we’ll make breaking changes without versioning.

Because the following changes are backwards compatible, we won’t update the API version. However, make sure to review Temenos APIs for changes that could benefit the development of your solution.

Backwards compatible changes include:

• Changing the length or content of a Temenos API identifier.
• Adding new API endpoints.
• Adding new optional parameters to existing endpoints.
• Adding new data elements to existing response schemas.
• Adding new enum values, including error_types and error_codes.
• Dividing existing error_types and error_codes into more precise errors, including relevant changes to the http response code, as required.*
• Adding new webhook_types and webhook_codes.

*Important note: Updating an error_type or error_code is a compatible change if the error can’t be resolved through retries or other developer actions during runtime. For example, changing error codes for some scenarios would be a breaking change, since the error can be resolved through retries. Converting an existing error to something more specific would not be.

Setting the Temenos API Version

You can configure the default version of the API you use in requests in your REST client or Temenos development platform. The default version is the latest version of the API, if version information isn’t specified.

You can also set the Temenos version header manually to use a specific version for a particular API request.

Client libraries

Temenos client libraries are pinned to the latest version of the API, at the time when they’re released. That means you can change to the latest API version by updating to the latest version of the client library.