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.

Changes in REST API v3

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