Pages Menu
TwitterRssFacebook

Posted by on Apr 1, 2020 in Development, Microsoft Teams | 0 comments

New Guidance on Microsoft Teams Throttling Service Limits

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

Teams request type Limit per app per tenant Limit per app across all tenants
Any Graph API calls for Microsoft Teams 15000 requests every 10 seconds n/a
GET team, channel, tab, installedApps, appCatalogs 60 rps 600 rps
POST/PUT channel, tab, installedApps, appCatalogs 30 rps 300 rps
PATCH team, channel, tab, installedApps, appCatalogs 30 rps 300 rps
DELETE channel, tab, installedApps, appCatalogs 15 rps 150 rps
GET /teams/{team-id}, joinedTeams 30 rps 300 rps
POST /teams/{team-id}, PUT /groups/{team-id}/team, clone 6 rps 150 rps
GET channel message 5 rps 100 rps
GET 1:1/group chat message 3 rps 30 rps
POST channel message 2 rps 20 rps
POST 1:1/group chat message 2 rps 20 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.”

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.

Post a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

This site uses cookies to help make this website better. By continuing to use this site we’ll assume you’re OK with that (implied consent).