Come join our live training webinar every other Wednesday at 11am PST and hear LogicMonitor experts explain best practices and answer common questions. We understand these are uncertain times, and we are here to help!
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.
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.
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.
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:
"name":"Prod Server 1"
"name":"Prod Server 1"
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).
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 query parameter values with special characters require encoding. Specifically:
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"
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"
When an unsuccessful request is made, the response body will contain an ‘errorCode’ field with one of the following codes:
"errorMessage": "Authentication failed",
In This Article