Throttling limits for Graph API (beta) managedDevices('{id}')/detectedApps

Question

I’m querying the Microsoft Graph beta endpoint /deviceManagement/managedDevices('{id}')/detectedApps and I’m consistently hitting throttling even when using batching (20 requests in a batch) and inserting a 20-second delay between batches.

The Graph documentation for Intune device service limits mentions:

• 4,000 requests per 20 seconds per tenant (for all apps), and
• 2,000 requests per 20 seconds per app per tenant.

I run this operation for multiple tenants in parallel, but I still don't believe that I hit these service limits, at least not with 20-second delay. Is there more precise documentation for endpoint throttling limits that I can follow?

The api doesn't return rety-after header so I can't refer it for backing off and I would prefer to avoid throttling entirely.

Answer 1

The throttling limits for the Microsoft Graph API, specifically for the Intune device management service, indicate that you can make up to 4,000 requests per 20 seconds for all apps per tenant and 2,000 requests per 20 seconds per app per tenant. However, these limits can be affected by several factors, including the total number of requests being made across all tenants and the specific endpoint being accessed.

Since you are querying the /deviceManagement/managedDevices('{id}')/detectedApps endpoint and experiencing throttling, it may be beneficial to consider the following:

1. Concurrent Requests: If you are running operations for multiple tenants in parallel, ensure that the combined requests do not exceed the throttling limits. Even with a 20-second delay between batches, if multiple tenants are making requests simultaneously, you could still hit the limits.
2. Batching: While you mentioned using batching, ensure that the total number of requests in each batch does not exceed the limits. Additionally, the batching mechanism itself may have its own limits that could contribute to throttling.
3. Retry Logic: Although the API does not return a Retry-After header, implementing a backoff strategy when you receive a throttling error can help mitigate the issue. Consider gradually increasing the delay between requests when throttling is detected.
4. Monitoring: Keep track of your request patterns and responses to identify any spikes that may lead to throttling. This can help you adjust your request strategy accordingly.

Unfortunately, there is no more precise documentation specifically for the endpoint throttling limits beyond what is provided in the general service limits documentation. You may want to monitor the Microsoft Graph documentation for any updates regarding throttling or specific endpoint limits.

---

References:

• Microsoft Graph service-specific throttling limits