About REST API v2

Overview

v2 of LogicMonitor’s REST API will allow you to programmatically query and manage your LogicMonitor resources: dashboards, devices, reports, websites, alerts, collectors, datasources, SDTs and more. Comprehensive documentation for available resources and methods can be found in our Swagger documentation. Additional information can be found in the sections below.

Note: For general information about LogicMonitor’s REST API, including authentication, rate limiting, and versioning information, see this page. Requests will default to v1 of the API, and you can make v2 requests by including a ‘?v=2’ query parameter or by including a ‘X-Version:2’ header.

Changes in REST API v2

v2 of LogicMonitor’s REST API features many differences (including non-backwards compatible ones) from v1. The following sections highlight the major differences, but please review v2 methods and resources for more details.

Status Codes

In v1 of the API, there were two status codes for a response: HTTP status code (almost always 200), and a different LM status code in the response body. With v2, we’re returning one HTTP status code, and we’ve considerably narrowed the list of possible status codes that will be returned. This change was made to ensure that response codes are as meaningful and actionable as possible.

Response Body Structure

In v1 of the API, successful responses included ‘status’, ‘errmsg’, and ‘data’ objects at the top level of the response. With 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 v1 of the API and configured to parse API response should be adjusted to reflect this.

Here is an example of a before and after response:

HTTP 200 
Response Body:
{ 
"status":200, 
"errmsg":"OK", 
"data": { 
     "id":34, 
     "name":"Prod Server 1" 
 } 
}

HTTP 200
Response Body:
{
     "id":34,
     "name":"Prod Server 1"
}

No Basic Authentication Support

We’ve removed support for basic authentication with v2 of the API. 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, more secure).

Support for PATCH

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).  You can determine whether PATCH is supported for a given resource by checking the Swagger documentation.

Filter Syntax

Filter query parameter values with special characters require encoding. Specifically:

• Filter query parameter values with special character "+" must be encoded twice.

  For example, the parameter value in this request GET /device/devices?filter=name:"Prod+Server" should be encoded twice for a result of: "Prod%252BServer"

• Filter query parameter values with special characters EXCEPT "+" (&, -, and so on) must be encoded once.

  For example, the parameter value in this request GET /device/devices?filter=name:"Prod&Server" should be encoded once for a result of: "Prod%26Server"

Supported Status Codes

When an unsuccessful request is made, the response body will contain an ‘errorCode’ field with one of the following codes:

Examples

GET /device/devices?v=2&fields=name,id&size=2
HTTP 200 
Response Body:
{
"total": 222,
"items": [
{
"id": 3,
"name": "ilo-mx233700hu.usa.lab"
},
{
"id": 5,
"name": "idrac-r610.csc.lab"
}
],
"searchId": null,
"isMin": false
}

GET /device/devices?v=2&fields=name,id&size=2 
HTTP 404 
Response Body:
{
"errorMessage": "Authentication failed",
"errorCode": 1401,
"errorDetail": null
}