Principles for monetizing selected Microsoft 365 APIs 

Microsoft Graph team

Microsoft offers access to Microsoft 365 API endpoints, including Microsoft Graph and its precursor APIs, through a licensing entitlement included with the purchase of certain products. As a result, developers have historically used these APIs at no additional cost.  

We are excited that the scope and usage of our APIs has grown dramatically over the past years. All along, we’ve aspired to ensure fair access to all customers. To make that possible, we have always had throttling limits to protect the reliability of the system. Today, API usage has grown to the point that apps, including some considered business-critical, frequently exceed our services’ throttling limits. Customers and developers are asking us for increased bandwidth and enriched functionality, purpose-built for specific scenarios.  

To power the next generation of these business-critical applications, we are exploring new advanced capabilities that empower developers with enriched functionality and data access at scale.  

For example, over the last year, Microsoft introduced Azure-metered access to some new Microsoft 365 APIs and services. We started with Microsoft Graph Data Connect, and recently started metering a select set of Teams API endpoints on Microsoft Graph APIs. 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. We are adding new value and making it available on a pay-as-you-go model. In this blog, we share some of the thoughts and principles behind how we are approaching these new metered services.   

Principles 

Here are the working principles that guide our approach to Microsoft 365 API endpoints.  

• Customer Data ownership: Customer data belongs to the customer. Learn more about how Microsoft categorizes customer data. 
• Reasonable access: We include access to Customer content, within defined limits, in our user license, and provide developer experiences and documentation focused on cohesion, simplicity, and transparency – around reasonable usage, throttling limits, and pricing. 
• Trust: We understand the importance of the trust our developers, partners, and customers place in us. A change to a generally available API would always follow our breaking change policy. 
• Ecosystem health: We strive for a balance between platform access and cost to ensure the health of our current and future ecosystem. 

Categories of services 

With these principles in place, we want to address three categories of use cases. Note that these categories are useful for illustration but don’t reflect any formal naming or branding. 

• Standard: this category includes the broad set of APIs used by developers and customers to perform “CRUD” (create, read, update, delete) operations on customer content and administrative endpoints for service configuration. We continue to define and update the limits of reasonable access based on documented usage thresholds to protect our customer experience and encourage good API usage patterns. We will continue to include access to this category of APIs within the defined limits as part of the user license without any additional costs to developers. This will continue to be the default category for most new endpoints. 
• High-Capacity APIs: we want to ensure that our customers and developers have access to data at scale. High-capacity APIs may include a new tier of monetized services geared for business-critical applications with high usage patterns. This category also includes purpose-built, bulk-export services like Teams Export APIs and Microsoft Graph Data Connect, bulk-import capabilities such as Microsoft Graph Connectors, and future bulk export or import endpoints.  
•  Advanced APIs: The third category focuses offering access to data that’s enriched or aggregated by Microsoft or offering access to advanced functionality extended directly from Microsoft 365 infrastructure as we’ve done with Azure Communication Services.  

Looking ahead 

Our objective is to provide our customers and partners with clarity around our plans for consumption-based APIs to ensure they have the time to understand and integrate associated costs and value into their solution’s business model. Please share your questions and comments with us in the comments section of this blog.  We will schedule time to address feedback on an upcoming Microsoft 365 developer community call once we have gathered sufficient commentary and had time to put together thoughtful responses. 

Thanks, 

The Microsoft Graph team 

Microsoft Graph team

Follow