Throttling coming to Outlook APIs

We’ve been given some advance warning that, from April 21st, throttling will be applied to Outlook REST APIs and to the Outlook APIs that are part of Microsoft Graph.

This will affect all anything you contact via https://outlook.office.com/api or https://outlook.office365.com/api. On the Microsoft Graph it will apply to:

• User resources
• Photo resources
• Mail resources
• Calendar resources (users and groups)
• Contact resources
• Attachment resources
• Group conversations
• People and social resources

Here are my thoughts on this.

The limit is high

Firstly, we need to understand what the limit is in order to understand whether or not this will impact our applications.

The limit is 60 requests, per minute, per user/group, per app ID.

That’s actually pretty high. Whatever it is you’re doing, you shouldn’t be issuing a call every single second, per user. If you start hitting this limit, then I’d respectfully suggest that your code might need a re-architecture!

Reacting to the limit

However, even if you think you’ll never hit the limit, you should still code for that eventuality. There’s an artificial limit in place now, and that means it can change at any time without warning. Your code should be able to cope with a sudden change in the limit and gracefully back-off.

Luckily, there is a special response code which will be issued if you hit a limit. You’ll receive a 429 – Too Many Requests response.

Also, in this response will be two additional headers which you can use to work out what to do next:

Retry-After : this tells you the number of seconds you should wait before making another request.
Rate-Limit-Reason : this is a human explanation of why you’re being limited.

Coding Smarter

Can we be even smarter than just reacting to hitting the limit? Yes! There are 3 new headers which will allow you to track your “allocation usage” over time:

Rate-Limit-Limit : The maximum number of requests that the app is permitted to make per minute for the current user or group
Rate-Limit-Remaining : The number of requests remaining in the current rate limit window
Rate-Limit-Reset : The time at which the current rate limit window resets in UTC time

---

I actually really like the changes being made here. Firstly, the limit itself is in no way unreasonable; it makes sense and prevents the system from abuse. But, what really pleases me is the way that it’s been implemented, and the additional features and information being offered to developers to enable them to do a good job of managing the limit and making sure that it doesn’t impact on user experience. It would have been all too easy to implement a limit and enforce it by just turning away overages with a single “denied” message – but they went the extra mile and provided information about the process in the responses. Good job team!