REST API Change Log

This article highlights the changes to LogicMonitor REST API with each version. It will give you a clear view of how our APIs have evolved and improved.

General Changes

REST API v1 and v2 Sunset Notice

We have decided to sunset LogicMonitor REST API v1 and v2. We encourage you to migrate to API v3 starting April 2023. We will continue to support API v1 and v2 until October 2023 and then stop supporting them. We will communicate the end of support date in advance to help you migrate to API v3. For more info, see LogicMonitor REST API v1 and v2 Sunset.

REST API Filters

When you call the endpoint GET /alert/alerts with filters, previously, even if there were no new alerts the result was inconsistent and shuffled. We have fixed this issue. As long as no new alert is generated or an existing one cleared, the result does not shuffle and the sequence of alerts list remains consistent. For more info, see REST API Basic Filters and REST API Advanced Filters.

LMv1 Token

Applications consume APIs and SDKs to connect with multiple backend platforms which provide tokens/secrets for authentication of the APIs and SDKs with backend platforms. To authenticate, many times users enter the secrets/tokens along with the source code leading to major security issue. As a security measure, we have now revised the token format. 

LMv1 token is dynamically built using access_id+access_key+payload+time+http_method. It is valid only for 10 minutes, thus storing it or committing in the repository serves no purpose.

• access_id – Consist of alphanumeric characters of size 20. For example, 32WDPj2KIdZikg7g98SR
• access_key – Consist of alphanumeric characters of size 120. For example, lma_A4S8)Ps9^jT9[4YFN4S36yG~+uF[h4tG){]]827McL=E3RtaqED%+{(n2p%+LOTRhYjc3ZmQtNmI2MC00M2EzLWJlZjYtMGQ3MmVhOTEwYzA3L0BeLhN  

Changes in REST API v3

Addition of numOfKuberntesDevices field

We added a numOfKuberntesDevices field to the DeviceGroup API model. It is present in the response body of all the endpoints that refer to the DeviceGroup API model. It indicates the number of Kubernetes resources in the target group. It also includes the count of Kubernetes resources in the sub groups of the target group.

Examples: 

HTTP Method	API Response
GET PUT PATCH	santaba/rest/device/groups/{id}
POST GET	santaba/rest/device/groups

If you select:

• A root group (id = 1) – The response body will include a count of all Kubernetes devices present in the portal.
• A specific device group – The response body will include a count of Kubernetes devices present in that device group.

New Endpoints

The major highlight of REST API v3 is the addition of five new endpoints. They are:

• POST – /setting/datasources/{id}/audit
• POST – /setting/eventsources/{id}/audit
• POST – /setting/configsources/{id}/audit
• POST – /setting/propertyrules/{id}/audit
• GET – /setting/integrations/auditlogs

For more information, see REST API v3 Swagger Documentation.

Changes in REST API v2

LogicMonitor REST API v2 includes new features, including non-backwards compatibility.

Status Codes

In REST API v1, there were two status codes for a response: HTTP status code (almost always 200), and a different LogicMonitor status code in the response body. With REST API v2, we’re returning one HTTP status code, and we’ve considerably narrowed the list of possible status codes that will be returned. 

No Basic Authentication Support

We’ve removed support for basic authentication with REST API v2. We did this to encourage more use of API tokens for authentication, as there are many additional benefits (separation of UI / API access, audit log entries, and more secure).

Support for PATCH Method

REST API v2 includes support for HTTP PATCH for most resources. You may find this useful for updating just one field of a resource, instead of having to use PUT to update the entire resource (all fields). 

Response Body Structure

In REST API v1, successful responses included status, errmsg, and data objects at the top level of the response. With REST API v2, since the HTTP status now matches the LM status, the contents of ‘data’ will be returned at the top level for a successful response. A non-successful response will include error message fields. Note that this does mean that scripts written for REST API v1 and configured to parse API response should be adjusted to reflect this.