Microsoft clarifies its position on charging for API usage, defining 3 categories of endpoints

Microsoft recently released a blog post, titled “Principles for monetizing selected Microsoft 365 APIs“, laying out their thinking around charging for access.

This blog post was needed to address questions and concerns the community have had recently, and if anything is a little overdue. I’ve previous blogged about the monetization of various parts of Microsoft Graph, such as Data Connect (May 2021) and the Export APIs (October 2021).

My summary of the blog post is:

• Historically, API usage has always been free and included with product licenses
• Throttling is in place to protect all users, but some customers want to be able to pay to remove the throttling limits
• There are already some monetized categories of APIs, such as Data Connect and Export as well as separately monetized services such as Azure Communication Services
• Microsoft will continue to offer a way for customers to access their data, “within defined limits” as part of their product licenses and without additional cost.
• However, Microsoft may look to add “a new tier of monetized services geared for business-critical applications with high usage patterns”
• Any changes to existing GA APIs would have to be in line with Microsoft’s breaking change policy (24 month’s notice)

My thoughts

• Although the specific wording of the blog post says that Microsoft “may include a new tier of monetized services” for high-capacity APIs, I think we should expect this – otherwise there isn’t really much point in this blog post. There’s no other new information provided other than this idea that Microsoft has heard the feedback from some quarters that people will pay to remove the throttling limits, and it sounds like they intend to act on it.
• I’m not against these moves, as long as they are additive and don’t take anything anyway from existing solutions. The blog post says several things which calm my nerves in this area and make me think that we shouldn’t worry, such as:
  • “Customer data belongs to the customer.”
  • “We include access to Customer content, within defined limits, in our user license”
  • “With this new approach, it’s important to clarify that we are not changing how we license or charge for existing, generally available, Microsoft Graph APIs.” (their emphasis, not mine)
• I do think it would be a shame if we saw the existing throttling limits tightened once a chargeable model was in place to remove them. Even if more and more people are using the APIs, that should result in greater investment in order to keep the existing throttling limits in place (following the model that product licenses “pay” for Graph investment).
• There are some places where the architecture model used doesn’t easily lend itself to a free / premium model. For instance, there are change notifications for Teams messages as well as more transactional “CRUD” APIs. For someone building a serverless architecture solution, using change notifications would probably be a better option. However, this option is chargeable: not because there is a high throttle in place – just because it’s a change notification rather than a CRUD API. Unfortunately, I do think that this will dive poor architecture choices with teams choosing implementations based on total overall cost rather than on architectural fit.

In general, though, I’m very much in favour of this blog post. I appreciate the level of information shared and Microsoft providing us with their thinking around the future direction of Microsoft Graph.

How do you feel about this? Microsoft would like your feedback on it, in the comments of the original article – so if you feel strongly about this, let them know!