REST API Change Log

Last updated on 09 July, 2024

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

Updates in v207 Platform Release

In v207 Platform release, we have updated LogicMonitor REST API v3 Swagger with the accessGroups and accessGroupIds fields. You can find the fields in the response of the following API endpoints:

AppliesToFunctions

GET /setting/functions

GET /setting/functions/{id}

Datasources

GET /setting/datasources

GET /setting/datasources/{id}

ParameterTypeDescription
createdByString(Read only) The name of the user who created the access group.
nameString(Mandatory) The name of the access group. For example, LinuxGroup
tenantIdStringThe ID of the tenant and tenancy details.
descriptionStringThe description of the access group.
idInteger(Read only) The ID of the access group.
updatedOnInteger(Read only) Time when the access group was updated.
createdOnInteger(Read only) Time when the access group was created.
accessGroupIdIntegerThe ID of the access group.

Updates in v201 Platform Release

Starting with Platform release v201, in addition to the existing filter _all~ you can also use a new filter description~ to search for specific data.

  • _all – the filter performs full text search that is, keyword search based on usernameipdescription, and sessionid fields. The response fetches the result that match the value specified in the filter across the mentioned fields. Note that you will get generic result.
    Example – {{url}}/setting/accesslogs?filter=_all~"update value=false, old value=true"
    Here, the response is as follows:
    • "update value=false, old value=true"
    • "update value=true, old value=false"
    • Any response that has updatevaluefalseoldvalue, and true in it (in any sequence). For example, "update value of field is changed to true, field old value was false"
  • description – the filter performs exact text search that is, exact substring match. The search is based only on the description field. The response fetches the result that exactly match with the value specified in the description field. You will get limited but specific result.
    Example – {{url}}/setting/accesslogs?filter=description~"update value=false, old value=true"
    Here, the response is as follows:
    • "update value=false, old value=true"

Updates in v200 Platform Release

In v200 Platform release, we have updated LogicMonitor REST API v3 Swagger with the following fields:

  • Instance level threshold setting – alertTransitionInterval, alertClearInterval, and alertForNoData
  • Instance group level threshold setting – alertTransitionInterval, alertClearTransitionInterval, and alertForNoData
  • Resource group level threshold setting  alertTransitionInterval, alertClearTransitionInterval, and alertForNoData

The impacted API endpoints are:

  • GET /device/devices/{deviceId}/devicedatasources/{hdsId}/instances/{instanceId}/alertsettings
  • PUT /device/devices/{deviceId}/devicedatasources/{hdsId}/instances/{instanceId}/alertsettings/{id}
  • PATCH /device/devices/{deviceId}/devicedatasources/{hdsId}/instances/{instanceId}/alertsettings/{id}
  • GET /device/groups/{deviceGroupId}/datasources/{dsId}/alertsettings
  • PUT /device/groups/{deviceGroupId}/datasources/{dsId}/alertsettings
  • PATCH /device/groups/{deviceGroupId}/datasources/{dsId}/alertsettings
  • PUT /device/devices/{deviceId}/devicedatasources/{deviceDsId}/groups/{dsigId}/datapoints/{dpId}/alertconfig
  • PATCH /device/devices/{deviceId}/devicedatasources/{deviceDsId}/groups/{dsigId}/datapoints/{dpId}/alertconfig

Updates in v198 Platform Release

Updates to Swagger and SDK Files

In v198 Platform release, we have updated LogicMonitor REST API v3 Swagger and v3 Python and GO SDK files. The Swagger and SDK files will be available after v198 deployment to production is complete. For any questions, contact your LogicMonitor Customer Success Manager. For details, see REST API v3 Swagger Documentation.

Refer to the following table for the new API endpoints that are added to LogicMonitor REST API v3.

CategoryEndpointsPurpose
Device GroupsPOST /azure/functions/discoverSubscriptions
POST /azure/functions/testAccount
GET /aws/accountId
POST /aws/functions/testAccount
POST /saas/functions/testAccount
POST /gcp/functions/testAccount
View subscription IDs
Test Azure account
Get AWS account ID
Test AWS account
Test SaaS account
Test GCP account
ReportGET /report/reports/{id}/tasks/{taskId}Run a report
userdataPATCH /setting/userdata/{id}
PUT /setting/userdata/{id}
Update default Dashboard
ConfigSourceGET /setting/configsources/{id}/updatereasonsGet update history for a configSource
DatasourcesPOST /setting/datasources
PUT /setting/datasources/{id}
PATCH /setting/datasources/{id}
Add datasource
Update datasource
Dashboard GroupsPOST /dashboard/groups/{id}/asynccloneAdd dashboard group asynchronously
DataSource InstancesPOST /device/devices/{deviceId}/devicedatasources/{deviceDsId}/groups
PUT /device/devices/{deviceId}/devicedatasources/{deviceDsId}/groups/{id}
PATCH /device/devices/{deviceId}/devicedatasources/{deviceDsId}/groups/{id}
Add device datasource instance group 
Update device datasource instance group 
DataPOST /device/instances/datafetchFetch device instance data
DeltaGET /device/devices/delta
GET /device/devices/delta/{deltaId}
Get filter matched devices with new Delta ID
Get delta devices using Delta ID

Refer to the following table for the API endpoints that are removed from LogicMonitor REST API v3.

CategoryEndpoint
DatasourcesPOST /setting/datasources/{id}/audit
ConfigSourcePOST /setting/configsources/{id}/audit
PropertySourcesPOST /setting/propertyrules/{id}/audit 
EventSourcesPOST /setting/eventsources/{id}/audit

Block Access to LM REST API v4 using Bearer Token

Starting with v198 release, you will not be able to use bearer token to authenticate yourself to use LogicMonitor REST API v4 external endpoints. We have already disabled Basic and LMv1 authentication to use API v4. Note that API v4 is not officially supported. We recommend you to use LogicMonitor REST API v3.

Bearer Token Support for Python and GO SDK

You can now use Bearer token to authenticate yourself to use GO and Python v3 SDK. The SDK files will be available after v198 deployment to production is complete. For any questions, contact your LogicMonitor Customer Success Manager. For details, see LogicMonitor v3 SDK.

Additional Updates

  • Due to performance issue, we removed customColumn from  /alert/alerts and /alert/alerts/id response. Similarly, we also removed detailMessage from  /alert/alerts response. However, users can still see detailMessage in /alert/alerts/id response.
  • Updated deviceType description in Device model. The deviceType field value is now set to ‘0’.
  • Due to performance issue, we removed customColumn request parameter from GET /alert/alerts/{id} and GET /alert/alerts

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 2024 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 MethodAPI 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.

In This Article