Rate Limiting

Overview

Rate 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.

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.

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 tables list default rate limits per endpoint/method request combination.

Alert Rules

Alerts

API Tokens

ApiPerfStats

AppliesToFunctions

Audit Logs

Collector Groups

Collectors

Collector Versions

ConfigSources

Dashboard Groups

Dashboards

Data

Datasource Instances

Datasources

Debug

Device Groups

Devices

Escalation Chain

EventSources

IntegrationAuditLogs

Metrics

Netscans

Ops Notes

PropertySources

Recipient Groups

Report

Report Groups

Roles

SDTs

Thresholds

Users

Website Groups

Websites

Widgets