Skip to content

Latest commit

 

History

History
533 lines (382 loc) · 34.4 KB

throttling-limits.md

File metadata and controls

533 lines (382 loc) · 34.4 KB
Raw
title description ms.localizationpriority ms.custom ms.subservice ms.date
Microsoft Graph service-specific throttling limits
Identify the throttling limits for each Microsoft Graph service to apply best practices to manage throttling in your application.
high
graphiamtop20
non-product-specific
06/19/2024

Microsoft Graph service-specific throttling limits

Microsoft Graph allows you to access data in multiple services, such as Outlook or Microsoft Entra ID. These services impose their own throttling limits that affect applications that use Microsoft Graph to access them.

Any request can be evaluated against multiple limits, depending on the scope of the limit (per app across all tenants, per tenant for all apps, per app per tenant, and so on), the request type (GET, POST, PATCH, and so on), and other factors. The first limit to be reached triggers throttling behavior. In addition to the service specific-limits described in the section, the following global limits apply:

Request type Per app across all tenants
Any 130,000 requests per 10 seconds

Note

The specific limits described here are subject to change.

In this section, the term tenant refers to the Microsoft 365 organization where the application is installed. This tenant can be the same as the one where the application was created in the case of a single-tenant application, or it can be different in the case of a multi-tenant application.

Assignment service limits

The following limits apply to requests on the assignment service API:

Request type Limit per app per tenant Limit per tenant for all apps
Any 500 requests per 10 seconds 1,000 requests per 10 seconds
Any 15,000 requests per 3,600 seconds 30,000 requests per 3,600 seconds
GET me/Assignment 50 requests per 10 seconds 150 requests per 10 seconds

The preceding limits apply to the following resources:

Bookings service limits

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.

Limit Applies to
Four concurrent requests v1.0 and beta endpoints

The preceding limits apply to the following resources:

Cloud communication service limits

Resource Limits per app
Calls 50,000 requests in a 15-second period, per application per tenant
Meeting information 2,000 meetings/user each month
Presence 1,500 requests in a 30-second period, per application per tenant
Virtual event 10,000 requests/app each month

Call records limits

The limits listed in the following table apply to the following resources:

Limit type Limit
Per application for all tenants 15,000 requests per 20 seconds
Per tenant for all applications 10,000 requests per 20 seconds
Per application per tenant 1,500 requests per 20 seconds
Per call record 10 requests per 20 seconds (first page)
50 requests per 5 minutes (subsequent pages)
List call records 15 requests per 20 seconds (first page)
55 requests per 5 minutes (subsequent pages)

PSTN call records limits

The limits listed in the following table apply to the following resources:

Limit type Limit
Per tenant 1,000 requests per 60 seconds
Per application per tenant 200 requests per 60 seconds
Per collection 50 requests per 60 seconds

Excel service limits

For explanations and best practices related to Excel service throttling, see Reduce throttling errors. In addition, following are some throttling limits.

[!INCLUDE Excel throttling documentation]

Education service limits

[!INCLUDE Education rostering APIS throttling documentation]

Files and lists service limits

For service limits for OneDrive, OneDrive for Business, and SharePoint Online, see Avoid getting throttled or blocked in SharePoint Online.

The preceding information applies to the following resources:

[!INCLUDE Files and lists throttling documentation]

Identity and access reports service limits

Request type Limit per app per tenant
Any Five requests per 10 seconds

The preceding limits apply to the following resources:

[!INCLUDE Azure AD identity and access reports throttling documentation]

Identity and access reports best practices

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, try reducing the amount of data returned. Try these approaches first:

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

Identity and access service limits

Pattern

Throttling is based on a token bucket algorithm, which works by adding individual costs of requests. The sum of request costs is then compared against predetermined limits. Only the requests exceeding the limits are throttled. If any of the limits are exceeded, the response is 429 Too Many Requests. It's possible to receive 429 Too Many Requests responses even when the following limits aren't reached, in situations when the services are under an important load or based on data volume for a specific tenant. The following table lists existing limits.

Limit type Resource unit quota Write quota
application+tenant pair S: 3,500 ResourceUnits per 10 seconds
M: 5,000 ResourceUnits per 10 seconds
L: 8,000 ResourceUnits per 10 seconds		 3,000 requests per 2 minutes and 30 seconds
application 150,000 ResourceUnits per 20 seconds 35,000 requests per 5 minutes
tenant Not Applicable 18,000 requests per 5 minutes

Note

The application + tenant pair limit varies based on the number of users in the tenant requests are run against. The tenant sizes are defined as follows: S - under 50 users, M - between 50 and 500 users, and L - above 500 users.

[!INCLUDE Identity and access throttling documentation]

The following table lists base request costs. Any requests not listed have a base cost of 1.

Operation Request Path Base Resource Unit Cost Write Cost
GET applications 2 0
GET applications/{id}/extensionProperties 2 0
GET contracts 3 0
POST directoryObjects/getByIds 5 0
GET domains/{id}/domainNameReferences 4 0
POST getObjectsById 5 0
GET groups/{id}/members 3 0
GET groups/{id}/transitiveMembers 5 0
POST isMemberOf 4 0
POST me/checkMemberGroups 4 0
POST me/checkMemberObjects 4 0
POST me/getMemberGroups 2 0
POST me/getMemberObjects 2 0
GET me/licenseDetails 2 0
GET me/memberOf 2 0
GET me/ownedObjects 2 0
GET me/transitiveMemberOf 2 0
GET oauth2PermissionGrants 2 0
GET oauth2PermissionGrants/{id} 2 0
GET servicePrincipals/{id}/appRoleAssignments 2 0
GET subscribedSkus 3 0
GET users 2 0
GET Any identity path not listed in the table 1 0
POST Any identity path not listed in the table 1 1
PATCH Any identity path not listed in the table 1 1
PUT Any identity path not listed in the table 1 1
DELETE Any identity path not listed in the table 1 1

Important

The cost of POST, PATCH, and DELETE operations on the applications request path depends on the signInAudience type. For apps where the signInAudience is AzureADMyOrg or AzureADMultipleOrgs, the cost is 70,000 requests per 5 minutes; while for apps where the signInAudience is AzureADandPersonalMicrosoftAccount or PersonalMicrosoftAccount, the cost is 60 requests per minute.

Other factors that affect a request cost:

  • Using $select decreases cost by 1
  • Using $expand increases cost by 1
  • Using $top with a value of less than 20 decreases cost by 1
  • Creating a user in a Microsoft Entra ID B2C tenant increases cost by 4

Note

  • A request cost can never be lower than 1. Any request cost that applies to a request path starting with me/ also applies to equivalent requests starting with users/{id | userPrincipalName}/.
  • Using $select for directoryObjects/getByIds and getObjectsById will result in 2 ResourceUnits.

Additional headers

Request headers

  • x-ms-throttle-priority - If the header doesn't exist or is set to any other value, it indicates a normal request. We recommend setting priority to high only for the requests initiated by the user. This header can have one of the following values:
    • Low - Indicates the request is low priority. Throttling this request doesn't cause user-visible failures.
    • Normal - Default if no value is provided. Indicates that the request is default priority.
    • High - Indicates that the request is high priority. Throttling this request causes user-visible failures.

Note

Should requests be throttled, low priority requests will be throttled first, normal priority requests second, and high priority requests last. Using the priority request header does not change the limits.

Regular responses requests

  • x-ms-resource-unit - Indicates the resource unit used for this request. Values are positive integers.
  • x-ms-throttle-limit-percentage - Returned only when the application consumed more than 0.8 of its limit. The value ranges from 0.8 to 1.8 and is a percentage of the use of the limit. Callers can use this value to set up an alert and take action.

Throttled responses requests

  • x-ms-throttle-scope - for example, Tenant_Application/ReadWrite/9a3d526c-b3c1-4479-ba74-197b5c5751ae/0785ef7c-2d7a-4542-b048-95bcab406e0b. Indicates the scope of throttling with the following format <Scope>/<Limit>/<ApplicationId>/<TenantId|UserId|ResourceId>:
    • Scope: (string, required)
      • Tenant_Application - All requests for a particular tenant for the current application.
      • Tenant - All requests for the current tenant, regardless of the application.
      • Application - All requests for the current application.
    • Limit: (string, required)
      • Read: Read requests for the scope (GET)
      • Write: Write requests for the scope (POST, PATCH, PUT, DELETE...)
      • ReadWrite: All Requests for the scope (any)
    • ApplicationId (Guid, required)
    • TenantId|UserId|ResourceId: (Guid, required)
  • x-ms-throttle-information - Indicates the reason for throttling and can have any value (string). The value is provided for diagnostics and troubleshooting purposes, some examples include:
    • CPULimitExceeded - Throttling is because the limit for cpu allocation is exceeded.
    • WriteLimitExceeded - Throttling is because the write limit is exceeded.
    • ResourceUnitLimitExceeded - Throttling is because the limit for the allocated resource unit is exceeded.

Identity and access data policy operation service limits

Request type Limit per tenant
POST on exportPersonalData 1,000 requests per day for any subject and 100 per subject per day
Any other request 10,000 requests per hour

The preceding limits apply to the following resources:

Note

The resources listed earlier do not return a Retry-After header on 429 Too Many Requests responses.

Identity protection and conditional access service limits

Request type Limit per tenant for all apps
Any One request per second

[!INCLUDE Information protection throttling documentation]

Note

The resources listed earlier do not return a Retry-After header on 429 Too Many Requests responses.

Identity providers service limits

[!INCLUDE CPIM throttling documentation]

Information protection service limits

The following limits apply to any request on /informationProtection.

For email, the resource is a unique network message ID/recipient pair. For example, submitting an email with the same message ID sent to the same person multiple times in a 15-minute period triggers the limit per resource limits listed in the following table. However, you can submit up to 150 unique emails every 15 minutes (tenant limit).

Operation Limit per tenant Limit per resource (email, URL, file)
POST 150 requests per 15 minutes and 10,000 requests per 24 hours One request per 15 minutes and 3 requests per 24 hours

[!INCLUDE Information protection throttling documentation]

Insights service limits

The following limits apply to any request on me/insights or users/{id}/insights.

Limit Applies to
10,000 API requests in a 10-minute period v1.0 and beta endpoints
Four concurrent requests v1.0 and beta endpoints

The preceding limits apply to the following resources:

Intune service limits

[!INCLUDE Intune tunnel throttling documentation] [!INCLUDE Intune android for work throttling documentation] [!INCLUDE Intune applications throttling documentation] [!INCLUDE Intune auditing throttling documentation] [!INCLUDE Intune books throttling documentation] [!INCLUDE Intune bundles throttling documentation] [!INCLUDE Intune chromebook sync throttling documentation] [!INCLUDE Intune company terms throttling documentation] [!INCLUDE Intune device config v2 throttling documentation] [!INCLUDE Intune device configuration throttling documentation] [!INCLUDE Intune device enrollment throttling documentation] [!INCLUDE Intune device intent throttling documentation] [!INCLUDE Intune devices throttling documentation] [!INCLUDE Intune endpoint protection throttling documentation] [!INCLUDE Intune enrollment throttling documentation] [!INCLUDE Intune GPAnalytics throttling documentation] [!INCLUDE Intune managed applications throttling documentation] [!INCLUDE Intune notifications throttling documentation] [!INCLUDE Intune ODJ throttling documentation] [!INCLUDE Intune partner integration throttling documentation] [!INCLUDE Intune rbac throttling documentation] [!INCLUDE Intune remote assistance throttling documentation] [!INCLUDE Intune telephony throttling documentation] [!INCLUDE Intune TEM throttling documentation] [!INCLUDE Intune troubleshooting throttling documentation] [!INCLUDE Intune unlock throttling documentation] [!INCLUDE Intune updates throttling documentation] [!INCLUDE Intune wip throttling documentation]

Invitation manager service limits

The following limits apply to any request on /invitations.

Operation Limit per tenant for all apps
Any operation 150 requests per 5 seconds

Microsoft 365 reports service limits

The following limits apply to any request on /reports.

Operation Limit per app per tenant Limit per tenant for all apps
Any request (CSV) 14 requests per 10 minutes 40 requests per 10 minutes
Any request (JSON, beta) 100 requests per 10 minutes n/a

The preceding limits apply individually to each report API. For example, a request to the Microsoft Teams user activity report API and a request to the Outlook user activity report API within 10 minutes count as one request out of 14 for each API, not two requests out of 14 for both.

The preceding limits apply to all usage reports resources.

Microsoft Teams service limits

Limits are expressed as requests per second (rps).

| Teams request type | Limit per app per tenant | Limit per app across all tenants | Limit per app per tenant per resource(chat/channel)| |------------------------------------------------------|---------------------------------|------------| | GET team | 30 rps | 600 rps | | GET channel | 30 rps | 600 rps | 1rps | | GET tab for channel, chat| 30 rps | 600 rps | 1rps | | GET installedApps for user, team | 30 rps | 600 rps | | GET installedApps for chat | 30 rps | 600 rps | 1rps | | GET appCatalogs | 30 rps | 600 rps | | POST channel | 30 rps | 300 rps | 1rps | | POST tab for channel or chat| 30 rps | 300 rps | 1rps | | POST installedApps for chat, user, team | 30 rps | 300 rps | | POST appCatalogs | 30 rps | 300 rps | | PATCH team, tab| 30 rps | 300 rps | | PATCH channel| 30 rps | 300 rps | 1rps | | DELETE channel | 15 rps | 150 rps | 1rps | | DELETE tab for chat, channel | 15 rps | 150 rps | 1rps | | DELETE installedApps for chat, user, team | 15 rps | 150 rps | | DELETE appCatalogs | 15 rps | 150 rps | | GET /teams/{team-id}, joinedTeams | 30 rps | 300 rps | | POST /teams | 10 rps | 100 rps | | PUT /groups/{team-id}/team| Six rps | 150 rps | | POST /{team-id}/ clone | Six rps | 150 rps | | GET channel message | 20 rps | 200 rps | 1rps | | GET 1:1/group chat message | 20 rps | 200 rps | 1rps | | POST channel message | 50 rps | 500 rps | 1rps | | POST chat member | 30 rps | 300 rps | 4rpm | | Delete chat member | 30 rps | 300 rps | 4rpm | | POST 1:1/group chat message | 20 rps | 200 rps | 1rps | | GET /teams/{team-id}/schedule and all APIs under this path | 30 rps | 600 rps | | POST /teams/{team-id}/schedule and all APIs under this path | 30 rps | 300 rps | |PUT /teams/{team-id}/schedule and all APIs under this path | 30 rps | 300 rps | | POST /teams/{team-id}/sendActivityNotification | Five rps | 50 rps | | POST /chats/{chat-id}/sendActivityNotification | Five rps | 50 rps | 1rps | | POST /users/{user-id}/teamwork/sendActivityNotification | Five rps | 50 rps | | POST /teamwork/sendActivityNotificationToRecipients | Two rps | 20 rps | | GET /teams/{team-id}/members | 60 rps | 1200 rps | | POST /teams/{team-id}/members | 30 rps | 300 rps | 4rpm| | GET /teams/{team-id}/channels | 60 rps | 1200 rps | 1rps | | GET /teams/{team-id}/channels/{channel-id}/members | 60 rps | 1200 rps | 1rps | | Get all channel messages for a team
GET teams/{team-id}/channels/getAllMessages
GET teams/{team-id}/channels/allMessages | 200rps | 1000rps | | Get all chat messages for a user
GET users/{user-id}/chats/getAllMessages
GET users/{user-id}/chats/allMessages | 200rps | 1000rps | | Other GET API calls for Microsoft Teams | 30 rps | 1500 rps | 1rps | | Other API calls for Microsoft Teams | 30 rps | 300 rps | 1rps |

A maximum of four requests per second per app can be issued on a given team.

A maximum of one request per second per app per tenant can be issued on a given channel or chat.

A maximum of one request per second per user can be issued when doing POST message in a given chat or channel (This throttling limit doesn't apply to migration).

A maximum of five requests per second per user can be issued when doing List chats or Get chat or chat:removeAllAccessForUser

See also Microsoft Teams limits and polling requirements.

[!INCLUDE Teams throttling documentation]

Multitenant management service limits

[!INCLUDE Multi tenant platform throttling documentation]

OneNote service limits

Limit type Limit per app per user (delegated context) Limit per app (app-only context)
Requests rate 120 requests per 1 minute and 400 per 1 hour 240 requests per 1 minute and 800 per 1 hour
Concurrent requests Five concurrent requests 20 concurrent requests

The preceding limits apply to the following resources:

[!INCLUDE Onenote throttling documentation]

You can find additional information about best practices in OneNote API throttling and how to avoid it.

Note

The resources listed earlier do not return a Retry-After header on 429 Too Many Requests responses.

Open and schema extensions service limits

Request type Limit per app per tenant
Any 455 requests per 10 seconds

The preceding limits apply to the following resources: [!INCLUDE Open and schema extensions throttling documentation]

Outlook service limits

Outlook service limits apply to the public cloud and national cloud deployments.

Limits per app ID and mailbox combination

The Outlook service applies limits to each app ID and mailbox combination - that is, a specific app accessing a specific user or group mailbox. Exceeding the limit for one mailbox doesn't affect the ability of the application to access another mailbox.

Limit Applies to
10,000 API requests in a 10 minute period v1.0 and beta endpoints
Four concurrent requests v1.0 and beta endpoints
150 megabytes (MB) upload (PATCH, POST, PUT) in a 5-minute period v1.0 and beta endpoints

Outlook service resources

API Resources
Search API (preview)
  • External item (Microsoft Search)
    		•
    Profile API
  • Photo
    		•
    Calendar API
  • event
  • eventMessage
  • calendar
  • calendarGroup
  • outlookCategory
  • attachment
  • place (preview)
    		•
    Mail API
  • message
  • mailFolder
  • mailSearchFolder
  • messageRule
  • outlookCategory
  • attachment
    		•
    Personal contacts API
  • contact
  • contactFolder
  • outlookCategory
    		•
    Social and workplace intelligence
  • person
    		•
    To-do tasks API (preview)
  • outlookTask
  • outlookTaskFolder
  • outlookTaskGroup
  • outlookCategory
  • attachment
    		•

    Outlook service limits for JSON batching

    When an app makes a JSON batch request that consists of multiple, unordered individual requests to the Outlook service, by default, Microsoft Graph sends the Outlook service up to four individual requests from the batch at a time, regardless of the target mailboxes of those requests. The Outlook service can execute these requests in parallel at any point, also irrespective of the target mailbox. Since Microsoft Graph sends only up to four requests to run in parallel, the execution of that batch stays within Outlook's concurrency limits for the same mailbox.

    Alternatively, an app can use the dependsOn property to order requests within a batch. Microsoft Graph sends the Outlook service one request from the batch at a time following the specified order, and Outlook executes each individual request in the batch sequentially.

    In other words, when targeting the same mailbox, apps that allow multiple batch requests to run in parallel can use either of the following approaches:

    • If the individual requests don't have to be ordered, have individual requests from a single batch run concurrently.
    • Use the dependsOn property to order requests in a batch, and have up to four such batch requests run concurrently.

    Project Rome service limits

    Request type Limit per user for all apps
    GET 400 requests per 5 minutes and 12,000 requests per one day
    POST, PUT, PATCH, DELETE 100 requests per 5 minutes and 8,000 requests per one day

    The preceding limits apply to the following resources:

    Security detections and incidents service limits

    The following limits apply to any request on /security.

    Operation Limit per app per tenant
    Any operation on alert, securityActions, secureScore 150 requests per minute
    Any operation on tiIndicator 1,000 requests per minute
    Any operation on secureScore or secureScorecontrolProfile 10,000 API requests in a 10-minute period
    Any operation on secureScore or secureScorecontrolProfile Four concurrent requests

    Security eDiscovery service limits

    The following limits apply to any request on /security/eDiscoveryCases.

    Operation Limit per app per tenant
    Any Five requests per minute

    Service Communications service limits

    The following limits apply to any type of requests for service communications under /admin/serviceAnnouncement/.

    Request type Limit per app per tenant
    Any 240 requests per 60 seconds
    Any 800 requests per hour

    Subscription service limits

    [!INCLUDE Subscription services throttling documentation]

    Tasks and plans service limits

    Service limits for Planner aren't available.

    The preceding information applies to the following resources: [!INCLUDE Tasks and plans throttling documentation]

    Viva Engage service limits

    Viva Engage API calls are subject to rate limiting, allowing 10 requests per user, per app, within a 30-second time period. When you exceed the rate limit, all subsequent requests return a 429 Too Many Requests response code.

    Related content