- About LogicMonitor
- Cloud Monitoring
- Dashboards and Widgets
- Getting Started
- LM Service Insight
- Rest API Developers Guide
- REST API Overview
- REST API v1
- REST API v1 Examples
- REST API v1 Status Codes
- Managing Ops Notes with the REST API
- Managing Alert Rules with the REST API
- Managing Alerts with the REST API
- Managing API Tokens with the REST API
- Accessing Audit Logs with the REST API
- Managing Collectors with the REST API
- Managing Collector Groups with the REST API
- Managing Dashboards and Widgets with the REST API
- Managing Dashboard Groups with the REST API
- Getting Data with the REST API
- Managing Datasources with the REST API
- Managing Datasource Instances with the REST API
- Managing Devices with the REST API
- Managing Device Groups with the REST API
- Get devices for a particular device group
- Get all alerts for a Device Group
- AWS Device Groups
- Delete Device Group Properties
- Update Device Group Properties
- Get Device Group Properties
- Add Device Group Properties
- Get all SDTs for a Device Group
- Delete a Device Group
- Get Device Groups
- Update a Device Group
- Add a Device Group
- About the Device Group Resource
- Managing Escalation Chains with the REST API
- Managing Reports with the REST API
- Managing Report Groups with the REST API
- Managing Roles with the REST API
- Managing SDTs with the REST API
- Managing Websites with the REST API
- Managing Website Groups with the REST API
- Getting Websites Test Locations with the REST API
- Managing Thresholds with the REST API
- Managing Users with the REST API
- REST API v2
- LogicMonitor SDKs
- RPC API Developers Guide - Deprecated
- Servicenow CMDB Integration
- Terminology and Syntax
The LogicMonitor REST API will allow you to programmatically query and manage your LogicMonitor resources: dashboards, devices, reports, services, alerts, collectors, datasources, SDTs and more.
Note that any API calls not documented in LogicMonitor’s RPC & REST Developer Guides are considered unpublished. We advise against using unpublished API calls as they are subject to change without notice, use of them will likely result in scripts breaking & LogicMonitor’s Technical Support will be unable to assist you with any issues you encounter.
- Base URL
- Rate Limiting
- Status Codes
- More information about REST
The base URL for making REST API requests is:
Only API calls for certain resources are available at this time. Resources will be posted to documentation as they become available. A current list of resources and methods available for v1 of LogicMonitor’s API is currently available here.
LogicMonitor’s REST API is versioned as follows:
- Semantic versioning will be used and called out in release notes, but only major version is allowed in requests (the most recent minor / patch versions will always be returned)
- The two latest published major versions will be supported
- Version can be specified in an ‘X-Version’ header, or in the URL as a query parameter
For example, if I include a header ‘X-Version:1’ in my request, I will get version 1.0.0 of the resource requested (assuming it is one of the latest two published versions). If I include a query parameter v=1, e.g. /device/devices?v=1, I will get version 1.0.0 of the devices resource (assuming it is one of the latest two published versions). If I omit the ‘X-Version’ header and v=version query parameter all together, I will get the oldest published version of the requested resource.
Currently, the following versions are supported:
Each request sent to the LogicMonitor server must be made over HTTPS, and must also be authenticated. All data is received as JSON. LogicMonitor’s REST API currently supports two authentication methods:
NOTE that Basic Authentication is only supported in v1 of the API, and may not be available with future versions of the API. As such, we highly recommend that you make REST API requests with API Token Authentication where possible.
LogicMonitor’s REST API currently supports HTTP Basic Authentication. To use HTTP Basic Authentication, each request must include an HTTP header with the following authentication information: “Authorization:Basic `echo -n username:password | base64`”
Almost all web clients support HTTP basic authentication and will construct this header for you.
LMv1 API Token Authentication
The recommended authentication method for LogicMonitor’s REST API is our LMv1 API Token Authentication. This authentication method requires that with every request you include a custom HTTP header containing your API Token Access Id, a base64 encoded HMAC signature based on your API Token Access Key, and a timestamp in epoch milliseconds.
Specifically, you will need to concatenate request details to form a string, and use your Access Key to calculate the HMAC-SHA256 of that string. You will then need to base64 encode the result. The complete base64 encoded HMAC signature should be in the following format:
And the full authentication header must be in the following format:
When LogicMonitor servers receive an API request, we first ensure the specified timestamp is within 30 minutes of the current time. If that requirement is satisfied, we retrieve the Access Key associated with the specified Access Id and compute the signature in the above format. We then compare that signature to the signature included in the request. If the two signatures match, the request is authenticated, but still subject to the permissions associated with the API Token (the token Access Id and Access Key must have sufficient permission to perform the requested action). In the event that the two signatures do not match, an error will be returned.
Note: Query parameters (e.g. filter, fields, sort, ,size, etc.) are not considered part of the resource path, and should not be included in the calculation of the LMv1 authentication signature.
Rate limits are imposed for requests to LogicMonitor’s REST API. Limits will be per endpoint and method combination. For example, requests to GET /device/devices may have a different limit from requests to POST /device/devices and from requests to GET /device/devices/ID/devicedatasources. Requests that are made in excess of the rate limits will get an HTTP 429 Too Many Requests & a response containing an error. Limits are not per user, and will apply to all requests made for your account.
Information about limits and proximity to limits is returned in the below response headers. This enables you to view the rate limits that will be imposed and adjust scripts as needed to work around them.
We recommend basing any logic intended to work around rate limiting on the above headers and their values, as the limits are subject to change. For example, you may introduce logic in your script that, when rate limits have been met, waits 60 seconds before making another request – the following are examples of such logic in different languages:
The following logic can be utilized in a loop using the requests module, and implements a simple timeout if the ‘X-Rate-Limit-Remaining’ header value gets to zero:
The following logic can be utilized in a loop using the net http library, and implements a simple timeout if the ‘X-Rate-Limit-Remaining’ header value gets to zero:
The following logic can be utilized in a loop using the Apache http library, and implements a simple timeout if the ‘X-Rate-Limit-Remaining’ header value gets to zero:
How you should work around rate limiting with PowerShell depends on how you’re making requests. The Invoke-RestMethod cmdlet throws out response headers unless an exception occurs, and as such we recommend attempting retries when an HTTP 429 is returned if using Invoke-RestMethod. For example, you could make the API request in a try catch loop, and retry if the resulting status is 429, like this:
Alternatively, you can use Invoke-WebRequest cmdlet and add logic based on the rate limiting response headers.
Status codes for v1 of LogicMonitor’s REST API can be found on this page.
More Information about REST
In this Article: