REST API Rate Limit
Last updated on 06 October, 2024Rate limits are imposed for requests to LogicMonitor’s REST API. Limits are assigned per endpoint and method combination. For example, requests to GET /device/devices may have a different limit than requests to POST /device/devices or 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 and a response containing an error. Limits are not per user, and will apply to all requests made for your account.
Important: Default limits are tested for occasional peak usage, and not continuous use of the API at these limits. Continuous use of the API at the rated limits can impact the overall performance of the portal. LogicMonitor gives the highest precedence to the portal availability and performance and, therefore, reserves the right to reduce the API limits from the defaults if portal performance, alerting, and data collection are adversely affected. If your needs exceed these design limits, please work with your customer success manager proactively to discuss possible options.
Rate Limit Information in Response Headers
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.
Header | Description |
X-Rate-Limit-Limit | Request limit per X-Rate-Limit-Window |
X-Rate-Limit-Remaining | The number of requests left for the time window |
X-Rate-Limit-Window | The rolling time window length with the unit of second |
Rate Limiting Logic
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 across various languages.
Python
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.
if (response.headers['X-Rate-Limit-Remaining'] == 0):
window = response.headers['X-Rate-Limit-Window']
time.sleep(float(window))
Ruby
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.
if resp['X-Rate-Limit-Remaining'].to_i == 0
sleep resp['X-Rate-Limit-Window'].to_i
end
Groovy
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.
remainingRequestsHeader = response.getHeaders('X-Rate-Limit-Remaining');
windowHeader = response.getHeaders('X-Rate-Limit-Window');
remainingRequests = remainingRequestsHeader[0].getValue();
window = windowHeader[0].getValue();
if (remainingRequests.toInteger() == 0){
Thread.sleep(window.toInteger() * 1000);
}
PowerShell
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, as shown in the following code example.
(Alternately, you can use Invoke-WebRequest cmdlet and add logic based on the rate limiting response headers.)
<# Make request & retry if failed due to rate limiting #>
$Stoploop = $false
do {
try {
<# Make Request #>
$response = Invoke-RestMethod -Uri $url -Method $httpVerb -Headers $headers
<# Print status and body of response #>
$status = $response.status
$body = $response.data| ConvertTo-Json -Depth 5
Write-Host "Status:$status"
Write-Host "Response:$body"
$Stoploop = $true
}
catch {
if ($response.status -eq 429){
Write-Host "Request exceeded rate limit, retrying in 60 seconds..."
Start-Sleep -Seconds 60
}
else {
Write-Host "Request failed, not as a result of rate limiting"
$Stoploop = $true
}
}
}
While ($Stoploop -eq $false)
Default Rate Limits
The following table lists the default rate limit per request type.
HTTP Method | Rate Limit |
DELETE | 300/m |
GET | 500/m |
PATCH | 250/m |
POST | 200/m |
PUT | 200/m |
Rate Limit Exceptions
The following table lists the rate limit per endpoint/method request combination.
HTTP Method | API Request | Rate Limit | Description |
GET | /santaba/rest/alert/alerts | 400/min | Get alert list |
GET | /santaba/rest/device/devices/{id}/alerts | 600/min | Get alerts |
GET | /santaba/rest/device/groups | 400/min | Get device group list |
GET | /santaba/rest/device/groups/{id} | 1000/min | Get device group by ID |
GET | /santaba/rest/device/devices/{deviceId}/properties | 700/min | Get device properties |
GET | /santaba/rest/device/devices | 700/min | Get device list |
GET | /santaba/rest/device/devices/{deviceId}/devicedatasources/{hdsId}/instances | 500/min | Get device instance list |
POST | /santaba/rest/setting/opsnotes | 100/min | Add opsnote |
GET | santaba/rest/swagger.json | 10/min | Swagger documentation |
POST | santaba/rest/device/instances/datafetch | 5/min | Get instances data |
Note: The endpoints which are not mentioned in the above table follow the default rate limit.