ManageEngine has implemented rate limiting on their API.

Posted by Sunsparc@reddit | sysadmin | View on Reddit | 32 comments

For anyone with ManageEngine, specifically ServiceDesk Plus Cloud like me, they have implemented a 10 request per minute rate limit on their API. If you're doing bulk operations such as pulling data for reporting or updating assets, this has implications for you. The rate limit is per endpoint.

API Rate Limiting in ServiceDesk Plus Cloud

The API rate limit in ServiceDesk Plus Cloud is set to 10 requests per minutefor a single user or IP address. This limit is enforced to prevent abuse, protect system performance, and ensure fair usage across all users.

Key Points: -Rate Limit: 10 requests per minute per user/IP.-Trigger: Exceeding this limit results in a"Too many requests detected"error.-Duration: The restriction applies temporarily (typically 10 minutes) to the specific URL or endpoint.-Scope: The block is per user/IP and does not affect other pages or endpoints. Why This Limit Exists: - Prevents automated or manual throttling attempts.- Ensures system stability and security.- Protects against potential denial-of-service (DoS) attacks.

Can the Limit Be Increased?

-No, the rate limit cannot be increased by users or administrators.- This is asystem-wide enforced limitand not configurable via settings.- If your use case requires higher throughput, consider:-Batching requeststo reduce frequency.- Implementingexponential backoffon retry logic.- ContactingManageEngine Supportto discuss enterprise-level solutions or dedicated API access (if applicable).>Note: If you're hitting this limit during normal usage, it may indicate inefficient API calls. Review your integration logic to optimize request frequency.

I tested this myself and it does indeed block you for 10 minutes if you attempt to make too many requests. I frequently do a lot of bulk updating and pulling data for reporting so I'll have to refactor all of my scripts based on this.

The suggestion from their Zia AI bot was to "simply batch your requests".

[-]

shsheikh@reddit

Do you have an official source? I believe you, but I want to leave a comment, if possible.

[-]

Sunsparc@reddit (OP)

Confirmation was from their Zia AI bot. I can provide a screenshot.

[-]

SikhGamer@reddit

As someone who has implemented rate limiting on several different platforms. This is a very poor implementation. Feels like day 0 vibe coded junior slop.

Rate limiting should not punish all users; only users who are abusing.

[-]

OregonTechHead@reddit

This is a very poor implementation.

I mean, it's Zoho....

[-]

Sunsparc@reddit (OP)

Well I AI slopped a Powershell rate limiting temporary patch just so I could get my onboarding and offboarding running.

[-]

Funny_Lasagna@reddit

Thanks for reporting, we use the on-prem version and this is a deal breaker for migration to their cloud version. Maybe I’ll look into NinjaOnes ticketing system.

[-]

music2myear@reddit

I'd reconsider NinjaOne given this other thread: https://old.reddit.com/r/sysadmin/comments/1tgjjkd/ninjaone_aggressive_retention_tactics/

[-]

vppencilsharpening@reddit

The answer might be right in that last part "consider:-Batching requests to reduce frequency"

A lot of services allow you to request more than one record at a time. If you need to request 250 or 300 objects, just request all 300 in ONE transaction and then filter out the record you don't need on the backend.

One request returning 300 records is often far less overhead for the provider than 250 requests returning one record each.

[-]

Sunsparc@reddit (OP)

That's simple for doing GET requests. What if I need to bulk PUT update 1,000+ assets?

[-]

vppencilsharpening@reddit

I can't speak for this specific system, but I've worked with others that allow you to submit multiple insert & update records in a single API call. The one I'm most familiar with is AWS Route53, which allows you submit up to 1,000 record inserts & updates per API call.

[-]

Sunsparc@reddit (OP)

Nope, doesn't support it.

It supports a paginated row_count, fetching 100 rows per page. After that, you have to make subsequent calls by incrementing the index. If you need 1,000 records, that's 10 calls of 100 records each. You've hit the limit for the minute and have to wait.

Each write operation is an individual call, there's no way to batch writes. If I'm trying to bulk update assets, it hits the assets/$id individual endpoint. So update 10 assets and you've hit the limit for the minute. Updating 500 records (which I do semi regularly) would take near an hour.

[-]

TaterSupreme@reddit

I would expect that it would possible to batch multiple objects into a single API call.

[-]

jwalker107@reddit

Sounds like they've offered guidance on how you can deal with it, by batching bulk reads or updates instead of individual API calls for each...is there a problem with that approach?

Rate-limiting cloud APIs is a totally normal thing to do, from an anti-DDOS perspective.

[-]

Sunsparc@reddit (OP)

I'm not necessarily complaining about rate limiting, I have to deal with it sometimes when querying Graph.

But a rate limit of 10 per minute is insanely low. I routinely query and correlate all users and assets in our SDP tenant. The limit is per endpoint. It also paginates at 100 records. So depending on how much data I need to query/update, it could take hours.

[-]

DimensionSuitable919@reddit

Okay, fair point. 10 rpm on an endpoint that truncates at 100 records is aggressively restrictive for an enterprise tool. Out of curiosity, does this vendor offer a webhook system? Sometimes when API limits are this artificially low, it's because the vendor expects you to stream events via webhooks instead of polling/querying the database directly for state changes.

[-]

Sunsparc@reddit (OP)

Nope nothing of the sort.

[-]

jwalker107@reddit

Oh ok, that tracks...paginating at 100 records could definitely be problematic. I hadn't considered that aspect of it.

Do they offer any parameters to cancel pagination or offer larger result sets for bulk operations? I've used some APIs that paginate by default but offer an option to avoid it.

[-]

netburnr2@reddit

10 requests per MINUTE is absurd.

[-]

Conlaeb@reddit

I have a service that's 60/minute and I find that utterly frustrating to deal with.

[-]

xxbiohazrdxx@reddit

10 req/min is insanely low.

[-]

Arudinne@reddit

Rate limits are fine when they are sane.

[-]

DimensionSuitable919@reddit

Wow, 10 requests per minute is incredibly restrictive for modern IT operations—especially for asset management and bulk updates. Refactoring everything to avoid that 10-minute lockout is going to be a chore. For anyone scrambling to fix their workflows, looking into middleware with built-in throttling like n8n or Make can save you from rewriting raw code. If you are stuck updating custom Python scripts, utilizing the Tenacity library for exponential backoff retries is probably the fastest way to handle those HTTP 429 errors safely. Thanks for the heads-up on this, definitely saves a few of us from wondering why our syncs suddenly start failing.

[-]

Sunsparc@reddit (OP)

I had already been looking into PSPolly module for other purposes so utilizing the Rate Limiting with Retry policy was pretty easy to implement, just tedious. Even built in a Circuit Breaker policy for if I get the 10 minutes enforced on me, to fail out the script.

[-]

progenrule@reddit

did they at least document the new limits or are you finding them by hitting 429s

[-]

Sunsparc@reddit (OP)

Hell no, just logged in to see my weekly reporting failing.

[-]

Sunsparc@reddit (OP)

It's per IP, not per user.

[-]

progenyofeniac@reddit

Says it’s per IP address