Graph API - Increase Rate Limiting/ Throttling

Question

Graph API - Increase Rate Limiting/ Throttling

Mark Babayev 226

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?

JamesTran-MSFT 36,906 Reputation points Microsoft Employee Moderator

2021-01-05T23:10:56.407+00:00
@Mark Babayev
Thank you for your post!

When it comes to MS GraphAPI throttling we suggest:

Reduce the number of operations per request.

Reduce the frequency of calls.

Avoid immediate retries, because all requests accrue against your usage limits.

For more details.

When it comes to asking our support team or dev teams to increase the throttling limit for GraphAPI calls, I've reached out to our engineering team to see if this is possible and will update as soon as I get an answer from their end.

If you have any other questions, please let me know.
Thank you for your time and patience throughout this issue.
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
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
Caleb 6 Reputation points

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
Mühling, Stefan 0 Reputation points

2024-10-30T13:49:22.37+00:00

I think it's time to go back to on-prem mailserver (non-Exchange). Even listing mails in inboxes isn't possible. graph-API is randomly hitting any limit (10, 500, 999) and sometimes doesn't even react to requests at all. At least useful responses would be great to at least have an idea which rate limit kicks in.
Gaurav 0 Reputation points

2025-01-17T18:57:50.5666667+00:00

Hey even I am getting 429 error for createLink endpoint did you get any solution ?

Thanks
Caleb 6 Reputation points

2025-01-18T02:48:07.42+00:00

I ended up getting a person email from Microsoft saying there are many undocumented limitations on their APIs. They could give me no way to get around these "bugs". Personally, I think this is unacceptable.
I ended up creating a complete shadow of all of my folder structures and moving files I didn't want to share into that. Then I shared the base folder which shares all children.

After a year of testing and headaches I moved my product to another provider. They have their own issues.

2 answers

Your answer

JamesTran-MSFT 36,906 Reputation points Microsoft Employee Moderator

2021-01-05T23:10:56.407+00:00

@Mark Babayev
Thank you for your post!

When it comes to MS GraphAPI throttling we suggest:

Reduce the number of operations per request.

Reduce the frequency of calls.

Avoid immediate retries, because all requests accrue against your usage limits.

For more details.

When it comes to asking our support team or dev teams to increase the throttling limit for GraphAPI calls, I've reached out to our engineering team to see if this is possible and will update as soon as I get an answer from their end.

If you have any other questions, please let me know.
Thank you for your time and patience throughout this issue.
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
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
Caleb 6 Reputation points

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
Mühling, Stefan 0 Reputation points

2024-10-30T13:49:22.37+00:00

I think it's time to go back to on-prem mailserver (non-Exchange). Even listing mails in inboxes isn't possible. graph-API is randomly hitting any limit (10, 500, 999) and sometimes doesn't even react to requests at all. At least useful responses would be great to at least have an idea which rate limit kicks in.
Gaurav 0 Reputation points

2025-01-17T18:57:50.5666667+00:00

Hey even I am getting 429 error for createLink endpoint did you get any solution ?

Thanks
Caleb 6 Reputation points

2025-01-18T02:48:07.42+00:00

I ended up getting a person email from Microsoft saying there are many undocumented limitations on their APIs. They could give me no way to get around these "bugs". Personally, I think this is unacceptable.
I ended up creating a complete shadow of all of my folder structures and moving files I didn't want to share into that. Then I shared the base folder which shares all children.

After a year of testing and headaches I moved my product to another provider. They have their own issues.

Answer 1

JamesTran-MSFT 36,906 Microsoft Employee Moderator

<<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!

Garrett Mitchell 11 Reputation points

2021-02-16T03:57:41.907+00:00

@JamesTran-MSFT the Graph limit was seriously reduced without warning in the middle of last year, see here: https://github.com/microsoftgraph/microsoft-graph-docs/issues/8760

The docs say the limit is 20: https://learn.microsoft.com/en-us/graph/known-issues#limit-on-batch-size -- which makes a lot of sense for a batching API. If the limit is 4, you might as well not have the batch API at all? This seems like the sort of thing that was changed accidentally, without realizing the impact. Is it possible that the limit changed for separate requests and that inadvertently affected calls to the batch endpoint? Any chance you can dig further and push for the limit of 20 (or at least 10) to return, for batched requests?
Stephan van Rooij 61 Reputation points MVP

2021-02-16T10:56:48.127+00:00

If increasing it all together isn't possible, we would also be helped with it being increased but with the extra condition that all the requests in the batch should be tied to the same resource. (You can batch up to 20 request if they are all to the same mailbox, or you can batch requests to multiple mailboxes but only 4 per mailbox).
Garrett Mitchell 11 Reputation points

2021-04-01T01:11:16.737+00:00

@JamesTran-MSFT any further updates here?
Mike Qu 11 Reputation points

2021-07-29T06:25:20.137+00:00

@JamesTran-MSFT @tbgangav-MSFT @Anshika Choubey

I fully agree with the rest of the fellow developers who have posted in this Q&A and in the linked Github thread.

We as the developers want to follow best practices for performance and reduce unnecessary computing costs for both our resources AND Microsoft's.

That is the reason we diligently research for solutions and techniques such as the Batch support for Graph API.

At one time, the limits imposed by Microsoft was quite reasonable. But as mentioned in these threads, out of nowhere we're suddenly stuck with this 4 concurrent limit for "Batch".

Please understand that we're not trying to abuse the Graph API by requesting higher limits. There are fully legitimate, real-world business needs that need to be solved. Someone may want to send out 20 individual emails without shared To/CC. Another person may need to do a small bulk update on calendar events.

To force us to split such small scaled operations into batches of 4, and even then constantly worrying about potentially triggering throttles between these "size 4" batches, is frankly embarrassing. We know Microsoft has the computing power to handle millions and millions of requests, why make life so hard for your own developers who are trying to create usable solutions for your paying Microsoft 365 business customers?

If you can kindly have your PMs, or a higher up, take another look at this and the linked Github thread, it would be greatly appreciated.
Garrett Mitchell 11 Reputation points

2021-10-20T18:30:36.187+00:00

@JamesTran-MSFT bump again, any new updates?

Answer 2

Marcelo Marmol 1

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.

Stephan van Rooij 61 Reputation points MVP

2021-10-22T08:22:24.73+00:00

You can use batching in the following way.

You split the calls per tenant and you can combine up to 20 calls IF you don't combine more then 4 calls for the same mailbox.

This requires some advanced queueing, but it can work.

My personal opinion is that they should relax the throttling rules a little bit. My proposal would still be:

relax the limit a little bit (up to 20 for instance) as long as all the requests in the batch are for the same resource. We can also add some extra header to make the graph-to-internal-server routing easier.

The provided "answer" keeps being repeated over and over. But at some point they changed the limit from 20 to 4 which makes using batches nearly useless.
When talking to Exchange things (calendar/mail/contacts/...) you can consider using the "old" Exchange web service, that you can also use with bearer tokens!

Share via

Graph API - Increase Rate Limiting/ Throttling

2 answers

Your answer