API Changelog

Uptrends' API will be improved and extended over time. We’ll add new endpoints and methods as needed for new functionality.

When adding new functionality, our goal is to stay backward-compatible. However, sometimes change is inevitable and a new version of the API may not be compatible with what you’ve coded and used so far. You should check the API changelog regularly to be on top of all changes and to act on changes when necessary.

If you are looking for the documentation of the API, please check out the articles in the category Uptrends' API.

Also, if you are interested in the changes to the Uptrends app, check out the general changelog.

August 2021

Announcement: deprecation of version 3 of our API

The Uptrends API currently supports two versions side-by-side. Version 3 is the older legacy version of our API, and version 4 is the currently recommended version. With a much more complete set of features, version 4 has been the focus of our development for some time. As such, we’ve decided to deprecate version 3 of our API, and it will be retired and become unavailable by December 2022.

For customers currently still making active use of version 3 of our API, it should be noted that it will still be supported up until that time. However, we do recommend switching over to making use of version 4 as soon as possible. To assist you in this, we’ve written an API v3 to v4 upgrade guide, which will cover the key differences between the two API versions and how to bridge them in your scripts and software.

July 2021

Breaking change: changes in OperatorGroup authorization response

The Uptrends API allows you to manage permissions for operators and operator groups, assigning roles such as Administrator, Financial operator, or allowing Infra access. The OperatorGroup API contains several options for retrieving, adding or deleting such permissions.

We have changed the way in which the permissions are specified for operator groups in the API, which could affect any automated creation, removal, or retrieval of information about operator group permissions you may have set up. Currently, retrieving information about permissions works by requesting:

GET /OperatorGroup/{operatorGroupGuid}/Authorization

which returns a response along the following lines (depending on which permissions have been set up for that particular operator group):

[
      {
        "AuthorizationId": "{authIdGuid1}",
        "AuthorizationType": "FinancialOperator",
        "OperatorGroupGuid": "{operatorGroupGuid}"
    },
    {
        "AuthorizationId": "{authIdGuid2}",
        "AuthorizationType": "AllowInfra",
        "OperatorGroupGuid": "{operatorGroupGuid}"
    },
    ...
]

Going forward, that same request will have its response simplified, simply listing the permissions granted and no other information. The response will no longer contain an operatorGroupGuid or AuthorizationId (the latter will disappear completely, meaning permissions will no longer have an individual GUID assigned to them). It will look like this:

{
    "FinancialOperator",
    "AllowInfra",
    ...
}

Adding a new operator group permission currently works by sending a POST request to:

/OperatorGroup/{operatorGroupGuid}/Authorization with a request body specifying an “AuthorizationType”. The currently available values for AuthorizationType for operator groups is available in the Uptrends API Swagger UI, under Models (at the bottom), and then OperatorGroupAuthorizationType.

Going forward, new permissions can be added to an operator group by sending a POST request to:

/OperatorGroup/{operatorGroupGuid}/Authorization/{authorizationType} without including a request body.

Deleting a permission from an operator group is currently done by sending a DELETE request to /OperatorGroup/{operatorGroupGuid}/Authorization/{authorizationGuid} - but as noted above, “authorizationGuid” will disappear entirely as an entity and can no longer be used. Instead, you can delete permissions by referring to them directly by name in the request URL: /OperatorGroup/{operatorGroupGuid}/Authorization/{authorizationType}

February 2021

Breaking change: sensitive values in multi-step API monitors

Our multi-step API monitor type allows you to execute multiple consecutive HTTP requests, where each new request uses one or more pieces of data retrieved from a previous request to perform its task. Often, one of the steps will involve submitting credentials to gain access to a particular resource. In the past, these credentials would be added as predefined variables to the monitor definition, and then marked as Sensitive.

To improve the security of how we handle such credentials, we’re going to be moving away from that setup. Instead, the credentials will be placed in the vault. With that change, the option to mark predefined variables as sensitive in multi-step API monitors becomes obsolete, and we will be removing it.

This will affect the way in which you can create or interact with multi-step API monitors through our API. Currently, the monitor definition for this monitor type will contain an array “PredefinedVariables”, where each of the individual variables has a true/false boolean “Sensitive”. In the near future, this boolean will be removed from the definition. If you wish to create or update an existing multi-step API monitor in your account through the Uptrends API, this field must no longer be included.

Change: renamed routing

For Uptrends APIv4 we have an inconsistent way of naming routes. In most cases singular is used, but plural on a few occasions. The route now contains only singular parts, e.g. /MonitorGroup/{monitorGroupGuid}/Member instead of /MonitorGroup/{monitorGroupGuid}/Members.

We still support the old routes for backwards compatibility.

By using the Uptrends website, you consent to the use of cookies in accordance with our Cookie Policy.