Graph API - Increase Rate Limiting/ Throttling

Mark Babayev 226 Reputation points
2021-01-05T11:03:47.837+00:00

We are using Graph API with application credentials - admin login for all tenant users.
Because of some specific heavy user we sometimes reach the throttling limit and receive a 429 error.
Retry doesn't help in this case because the user constantly receiving multiple emails a second.
For example, one of those users is "0719342a-b4b0-4996-a564-eff079bf03ba" in tenant "302fce84-5dde-4410-93e0-7683d18b89c9".

As far, the only feasible solution we see in asking the Microsoft Support Team to increase the throttling rate limit.

  • Is it possible for the Microsoft Support Team to increase the throttling limit (for app/for tenant/for mailbox)?
  • As far as I see, it is considered the DEV-level support, not the IT-level.
  • Which support team should we pointed to, the Azure-AD, the Exchange Server, or something else?
Microsoft Graph
Microsoft Graph
A Microsoft programmability model that exposes REST APIs and client libraries to access data on Microsoft 365 services.
10,666 questions
{count} vote

5 answers

Sort by: Most helpful
  1. JamesTran-MSFT 36,376 Reputation points Microsoft Employee
    2021-01-08T17:00:38.013+00:00

    <<Update from PG team>>

    @Mark Babayev
    Thank you for your time and patience throughout this issue.

    I just wanted to reach out and let you know that I had another discussion with one of our PM's and unfortunately, "Graph Throttling Limits cannot be changed neither increased or decreased." It's recommended to follow our Best practices to avoid throttling documentation when it comes to GraphAPI throttling.

    If you have any other questions, please let me know.
    Thank you!

    2 people found this answer helpful.

  2. David Cohen 1 Reputation point
    2021-08-05T10:55:20.137+00:00

    We have the same problem with the concurrency limit. We do not use batching, but we have calls coming from a client, as well as multiple threads on a server, that all interact with the same mailbox. Even though the concurrency limit is listed as 4, based upon the errors we've been having, it seems like it's lower than this.

    The application we developed is not designed to help us internally, but rather to serve paying Microsoft customers. The throttling limits make their experience worse, so I don't know how it's in Microsoft's interest to have such severe limits.

    I also saw that there is a 2,000 call per second limit shared between all tenants for an application. While we are nowhere close to hitting this, our platform is growing fast, and we may hit it at some point. I don't see how this limit can possibly help Microsoft, as it adds a maximum size cap for the number of users an application can be deployed at. If we reach that point, we will need to manage multiple identical applications, which is a pain in the neck for both us and Microsoft paying customers.

    I join the development community in requesting that Microsoft rethink their rate limits to make them more friendly to the users who are paying Microsoft money to use their applications.

    David

    0 comments No comments

  3. Marcelo Marmol 1 Reputation point
    2021-10-20T12:14:08.863+00:00

    I am also thinking how this can be manged while we get more clients on-board. Reaching a limit is just a matter of time. The path of having multiple applications looks like can not be avoided for large clients at least.


  4. HENRY HUANG 1 Reputation point
    2022-06-06T09:10:54.857+00:00

    Hi, our application also reach the throttling limit, I want to know if it is possiable that i set up azure application for each application instance, so that directly limit 4 concurrent requests per instance instand of Distributed Lock between the instances? @JamesTran-MSFT

    208686-image.png

    0 comments No comments

  5. Caleb 1 Reputation point
    2023-12-25T09:31:12.4566667+00:00

    I am also having a Limiting/ Throttling issue but after just 10 calls.

    Using the batch function does not help.

    Calling the CreateLink endpoint

    0 comments No comments