You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: concepts/throttling.md
+17-11Lines changed: 17 additions & 11 deletions
Original file line number
Diff line number
Diff line change
@@ -1,21 +1,22 @@
1
1
---
2
2
title: "Microsoft Graph throttling guidance"
3
-
description: "Find best practices for maintaining optimal performance of the Microsoft Graph service if an overwhelming number of requests occurs."
3
+
description: "Learn the best practices to avoid throttling and maintaining optimal performance should your app be throttled."
4
4
ms.localizationpriority: high
5
5
author: FaithOmbongi
6
6
ms.author: ombongifaith
7
-
ms.reviewer: Luca.Spolidoro
7
+
ms.reviewer: mariampo, Avinash.Chenoor
8
8
ms.subservice: non-product-specific
9
-
ms.date: 01/22/2024
9
+
ms.topic: overview
10
+
ms.date: 01/14/2025
10
11
ms.custom: graphiamtop20
11
12
#Customer intent: As a developer integrating with Microsoft Graph, I want to understand how to avoid throttling and how to handle throttling when it occurs.
12
13
---
13
14
14
15
# Microsoft Graph throttling guidance
15
16
16
-
Throttling limits the number of concurrent calls to a service to prevent overuse of resources. Microsoft Graph is designed to handle a high volume of requests. If an overwhelming number of requests occurs, throttling helps maintain optimal performance and reliability of the Microsoft Graph service.
17
+
Throttling limits the number of concurrent calls to a service to prevent overuse of resources. The Microsoft Graph service implements throttling limits to ensure service availability and reliability.
17
18
18
-
Throttling limits vary based on the scenario. For example, if you are performing a large volume of writes, the possibility for throttling is higher than if you are only performing reads.
19
+
Throttling limits vary based on the scenario. For example, if you're performing a large volume of writes, the possibility for throttling is higher than if you're only performing reads.
19
20
20
21
> [!NOTE]
21
22
> Solutions that need to extract a large volume of data from Microsoft Graph should use [Microsoft Graph Data Connect](data-connect-concept-overview.md) instead of the Microsoft Graph REST APIs. Microsoft Graph Data Connect allows organizations to extract Microsoft 365 data in bulk without being subject to throttling limits.
@@ -31,7 +32,12 @@ Throttling limits vary based on the scenario. For example, if you are performing
31
32
## What happens when throttling occurs?
32
33
<!-- markdownlint-enable MD026 -->
33
34
34
-
When a throttling threshold is exceeded, Microsoft Graph limits any further requests from that client for a period of time. When throttling occurs, Microsoft Graph returns HTTP status code 429 (Too many requests), and the requests fail. A suggested wait time is returned in the response header of the failed request. Throttling behavior can depend on the type and number of requests. For example, if you have a high volume of requests, all requests types are throttled. Threshold limits vary based on the request type. Therefore, you could encounter a scenario where writes are throttled but reads are still permitted.
35
+
When a throttling threshold is exceeded, Microsoft Graph:
36
+
- Limits any further requests from that client app for some time.
37
+
- Returns HTTP status code **429 Too Many Requests** and the requests fail.
38
+
- Returns a suggested wait time in the response header of the failed request.
39
+
40
+
Throttling behavior can depend on the type and number of requests. For example, if you have a high volume of requests, all requests types are throttled. Threshold limits vary based on the request type. Therefore, you could encounter a scenario where writes are throttled but reads are still permitted.
35
41
36
42
## Common throttling scenarios
37
43
@@ -77,20 +83,20 @@ When you implement error handling, use the HTTP error code 429 to detect throttl
77
83
78
84
1. Wait the number of seconds specified in the `Retry-After` header.
79
85
2. Retry the request.
80
-
3. If the request fails again with a 429 error code, you are still being throttled. Continue to use the recommended `Retry-After` delay and retry the request until it succeeds.
86
+
3. If the request fails again with a 429 error code, you're still being throttled. Continue to use the recommended `Retry-After` delay and retry the request until it succeeds.
81
87
82
-
All the resources and APIs described in the [Service-specific limits](throttling-limits.md) provide a `Retry-After` header except when noted.
88
+
All the resources and APIs described in the [Service-specific limits](throttling-limits.md) provide a `Retry-After` header except where indicated.
83
89
84
90
For a broader discussion of throttling in the Microsoft Cloud, see [Throttling pattern](/azure/architecture/patterns/throttling).
85
91
86
92
> [!NOTE]
87
-
> If no `Retry-After` header is provided by the response, we recommend implementing an exponential backoff retry policy. You can also implement [more advanced patterns](/azure/architecture/patterns/category/resiliency) when building large-scale applications.
93
+
> If no `Retry-After` header is provided by the response, we recommend implementing an exponential backoff retry policy. You can also implement [more advanced patterns](/azure/well-architected/reliability/design-patterns) when building large-scale applications.
88
94
>
89
95
> Microsoft Graph SDKs already implement handlers that rely on the `Retry-After` header or default to an exponential backoff retry policy.
90
96
91
97
## Best practices to avoid throttling
92
98
93
-
Programming patterns like continuously polling a resource to check for updates and regularly scanning resource collections to check for new or deleted resources are more likely to lead to applications being throttled and degrade overall performances. You should instead leverage[change tracking](delta-query-overview.md) and [change notifications](change-notifications-overview.md) when available.
99
+
Programming patterns like continuously polling a resource to check for updates and regularly scanning resource collections to check for new or deleted resources are more likely to lead to applications being throttled and degrade overall performances. You should instead use[change tracking](delta-query-overview.md) and [change notifications](change-notifications-overview.md) when available.
94
100
95
101
>[!NOTE]
96
102
>[Best practices for discovering files and detecting changes at scale](/onedrive/developer/rest-api/concepts/scan-guidance) describes best practices in details.
@@ -99,7 +105,7 @@ Programming patterns like continuously polling a resource to check for updates a
99
105
100
106
[JSON batching](./json-batching.md) allows you to optimize your application by combining multiple requests into a single JSON object. Requests in a batch are evaluated individually against throttling limits and if any request exceeds the limits, it fails with a status code of `429` and an error similar to the [preceding sample response](#sample-response). The batch itself succeeds with a status code of `200` (OK). Multiple requests can be throttled in a single batch. You should retry each failed request from the batch using the value provided in the `retry-after` response header from the JSON content. You may retry all the failed requests in a new batch after the longest `retry-after` value.
101
107
102
-
If SDKs retry throttled requests automatically when they are not batched, throttled requests that were part of a batch are not retried automatically.
108
+
If SDKs retry throttled requests automatically when they aren't batched, throttled requests that were part of a batch aren't retried automatically.
The Bookings service applies limits to each app ID and mailbox combination, specifically when a particular app accesses a particular booking mailbox. Exceeding the limit for one mailbox doesn't affect the ability of the application to access another mailbox.
10
+
11
+
| Limit | Applies to |
12
+
| -------------- | ------------ |
13
+
| Four concurrent requests | v1.0 and beta endpoints |
14
+
15
+
The preceding limits apply to the following resources:
<!-- this file is auto-generated don't edit it manually! -->
8
+
9
+
| Request type | Limit per app per tenant |
10
+
| ------------ | ------------------------ |
11
+
| Any | Five requests per 10 seconds |
12
+
13
+
The preceding limits apply to the following resources:
9
14
10
15
|<!-- fake header-->|<!-- fake header-->|
11
16
|--|--|
@@ -16,3 +21,8 @@ Verify the following: azureadfeatureusage, azureadlicenseusage, azureaduserfeat
16
21
17
22
Changed authenticationMethodsRoot to authenticationMethod
18
23
-->
24
+
25
+
### Identity and access reports best practices
26
+
Microsoft Entra reporting APIs are throttled when Microsoft Entra ID receives too many calls during a given timeframe from a tenant or app. Calls might also be throttled if the service takes too long to respond. If your requests still fail with a `429 Too Many Requests` error code despite applying the [best practices to handle throttling](/graph/throttling#best-practices-to-handle-throttling), try reducing the amount of data returned. Try these approaches first:
27
+
- Use filters to target your query to just the data you need. If you only need a certain type of event or a subset of users, for example, filter out other events using the `$filter` and `$select` query parameters to reduce the size of your response object and the risk of throttling.
28
+
- If you need a broad set of Microsoft Entra ID reporting data, use `$filter` on the **createdDateTime** to limit the number of sign-in events you query in a single call. Then, iterate through the next timespan until you have all the records you need. For example, if you're being throttled, you can begin with a call that requests three days of data and iterate with shorter timespans until your requests are no longer throttled.
0 commit comments