REST API Change Log
Last updated on 06 October, 2024This 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 v210 Platform Release
In v210 Platform release, we have updated LogicMonitor REST API v3 Swagger, v3 Python and GO SDK files with the following new endpoints.
Category | Endpoint | Purpose |
ConfigSources | PATCH/setting/configsources/{id} | Update ConfigSource by ID |
GET/setting/configsources/{id} | Get ConfigSource by ID | |
DELETE/setting/configsources/{id} | Delete ConfigSource by ID | |
PUT/setting/configsources/{id} | Update ConfigSource by ID | |
POST/setting/configsources | Add ConfigSource | |
GET/setting/configsources | Get ConfigSource list | |
EventSources | POST /setting/eventsources | Add EventSource |
PATCH /setting/eventsources/{id} | Update EventSource by ID | |
GET /setting/eventsources/{id} | Get EventSource by ID | |
DELETE /setting/eventsources/{id} | Delete EventSource by ID | |
PUT /setting/eventsources/{id} | Update EventSource by ID | |
JobMonitor | PATCH /setting/batchjobs/{id} | Update JobMonitor |
GET /setting/batchjobs/{id} | Get JobMonitor by ID | |
DELETE /setting/batchjobs/{id} | Delete JobMonitor | |
PUT /setting/batchjobs/{id} | Update JobMonitor | |
POST /setting/batchjobs | Add JobMonitor | |
GET /setting/batchjobs | Get JobMonitor list | |
OID | PATCH /setting/oids/{id} | Update an OID |
GET /setting/oids/{id} | Get OID by ID | |
DELETE /setting/oids/{id} | Delete an OID | |
PUT /setting/oids/{id} | Update an OID | |
POST /setting/oids | Add an OID | |
GET /setting/oids | Get OID list | |
PropertySource | PATCH /setting/propertyrules/{id} | Update a property rule |
GET /setting/propertyrules/{id} | Get property rules by ID | |
DELETE /setting/propertyrules/{id} | Delete a property rule | |
PUT /setting/propertyrules/{id} | Update a property rule | |
POST /setting/propertyrules | Add a property rule | |
GET /setting/propertyrules | Get property rules list | |
TopologySource | PATCH /setting/topologysources/{id} | Update TopologySource |
GET /setting/topologysources/{id} | Get TopologySource by ID | |
DELETE /setting/topologysources/{id} | Delete TopologySource | |
PUT /setting/topologysources/{id} | Update TopologySource | |
POST /setting/topologysources | Add TopologySource | |
GET /setting/topologysources | Get TopologySource List | |
Threshold | GET /device/devices/{deviceId}/devicedatasources/{hdsId}/instances/{instanceId}/alertsettings/{id} | Get a list of alert settings for a specific device datasource instance |
POST /device/groups/{deviceGroupId}/clusterAlertConf | Add cluster alert configuration | |
GET /device/groups/{deviceGroupId}/clusterAlertConf | Get a list of cluster alert configurations for a device group | |
DELETE /device/groups/{deviceGroupId}/clusterAlertConf/{id} | Delete cluster alert configuration | |
PATCH /device/groups/{deviceGroupId}/clusterAlertConf/{id} | Update cluster alert configuration | |
PUT /device/groups/{deviceGroupId}/clusterAlertConf/{id} | Update cluster alert configuration | |
GET /device/groups/{deviceGroupId}/clusterAlertConf/{id} | Get cluster alert configuration by ID | |
Devices | GET /device/devices/{deviceId}/alertsettings | Get all thresholds for all instances of a given device |
GET /device/devices/{id}/endpoints | Get NetFlow endpoints | |
GET /device/devices/{id}/ports | Get NetFlow ports | |
Data | GET /device/devices/{deviceId}/devicedatasources/{hdsId}/instances/{instanceId}/config/{id} | Get configuration for a device |
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}
Parameter | Type | Description |
createdBy | String | (Read only) The name of the user who created the access group. |
name | String | (Mandatory) The name of the access group. For example, LinuxGroup |
tenantId | String | The ID of the tenant and tenancy details. |
description | String | The description of the access group. |
id | Integer | (Read only) The ID of the access group. |
updatedOn | Integer | (Read only) Time when the access group was updated. |
createdOn | Integer | (Read only) Time when the access group was created. |
accessGroupId | Integer | The 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 onusername
,ip
,description
, andsessionid
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
update
,value
,false
,old
,value
, andtrue
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 thedescription
field. The response fetches the result that exactly match with the value specified in thedescription
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
, andalertForNoData
- Instance group level threshold setting –
alertTransitionInterval
,alertClearTransitionInterval
, andalertForNoData
- Resource group level threshold setting –
alertTransitionInterval
,alertClearTransitionInterval
, andalertForNoData
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.
Category | Endpoints | Purpose |
Device Groups | POST /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 |
Report | GET /report/reports/{id}/tasks/{taskId} | Run a report |
userdata | PATCH /setting/userdata/{id} PUT /setting/userdata/{id} | Update default Dashboard |
ConfigSource | GET /setting/configsources/{id}/updatereasons | Get update history for a configSource |
Datasources | POST /setting/datasources PUT /setting/datasources/{id} | Add datasource Update datasource |
Dashboard Groups | POST /dashboard/groups/{id}/asyncclone | Add dashboard group asynchronously |
DataSource Instances | POST /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 |
Data | POST /device/instances/datafetch | Fetch device instance data |
Delta | GET /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.
Category | Endpoint |
Datasources | POST /setting/datasources/{id}/audit |
ConfigSource | POST /setting/configsources/{id}/audit |
PropertySources | POST /setting/propertyrules/{id}/audit |
EventSources | POST /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 removeddetailMessage
from/alert/alerts
response. However, users can still seedetailMessage
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 fromGET /alert/alerts/{id}
andGET /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 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.