New Guidance on Microsoft Teams Throttling Service Limits

Microsoft have updated their guidance to developers of applications using the Microsoft Graph endpoint to retrieve, update, create or delete Microsoft Teams data.

In an update on March 25th, the following very specific limits were published:

Limits are expressed as requests per second (rps).

In addition to the above, there is an overall maximum of 4 requests per second, per app against a specific team or channel

This clarity around throttling limits is really helpful because it allows developers to incorporate these restrictions into their applications. There are already published best practices for responding to 429 error codes, but it can sometimes be hard to know how long to back-off for, with some calls not returning Retry-After headers. With the guidance above, developers can now make sure that their applications operate within the limits and are less likely to be affected by throttling.

However, this does not mean that developers shouldn’t build their applications to cope with throttling: they absolutely should. The limits set out above are likely to be the general limits and can be changed for operational reasons. Global events, such as the current COVID-19 pandemic may mean that all limits are temporarily reduced (given as an example, I have no evidence this is happening), so developers should use the best practice provided to ensure that their applications are able to respond to 429 requests correctly.

IT Admins should also take careful note of the per-tenant limits, especially if they have installed multiple applications which are likely to access Teams data regularly. These restrictions particularly are less likely to be well tested by ISVs and more likely to cause strange, hard-to-track problems in production environments.

It’s well worth keeping in mind the overall performance and capacity limits of Microsoft Teams as documented in Limits and specifications for Microsoft Teams. This page covers things like the total number of members in a team, number of channels in a team, max conversation post size, etc.

There are some other changes to published documentation around throttling and Graph service use which are worth calling out as well:

• if you app polls to see whether a resource has changed, you can only do that once per day (with the exception of using teamsAsyncOperation). Consider using subscriptions if you need to know more regularly than this.
• specifically to the ‘Send Message’ POST request to /teams/{id}/channels/{id}/messages/ – it’s not recommended that this is used for data migration as it lacks the throughput nessecary for most migrations. It’s not clear whether there are additional limits on top of the 2 rps listed in the table above.
• If you are polling for new messages, you must specify a date range where supported.  For details, see get channel messages delta.  (emphasis mine)

Apps that don’t follow these polling requirements will be considered in violation of the Microsoft APIs Terms of Use. This may result in additional throttling or the suspension or termination of your use of the Microsoft APIs.

Written by Tom Morgan

Tom is a Microsoft Teams Platform developer and Microsoft MVP who has been blogging for over a decade. Find out more.

---

Buy the book: Building and Developing Apps & Bots for Microsoft Teams. Now available to purchase online with free updates.

Related posts:

Throttling coming to Outlook APIs Using Microsoft Teams as a developer: new tooling coming soon! Using the Microsoft Teams BETA Graph API calls? They may be about to break on you… 3 API calls going away soon How to Manage Microsoft Teams & Send Messages using the Teams API in Microsoft Graph Weekly Update 28 September 2019: Graph Toolkit GA!, Podcasts at Microsoft Ignite, nor(DEV):mag article, Design Guidance for Teams