Customize Consent Preferences

We use cookies to help you navigate efficiently and perform certain functions. You will find detailed information about all cookies under each consent category below.

The cookies that are categorized as "Necessary" are stored on your browser as they are essential for enabling the basic functionalities of the site. ... 

Always Active

Necessary cookies are required to enable the basic features of this site, such as providing secure log-in or adjusting your consent preferences. These cookies do not store any personally identifiable data.

No cookies to display.

Functional cookies help perform certain functionalities like sharing the content of the website on social media platforms, collecting feedback, and other third-party features.

No cookies to display.

Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics such as the number of visitors, bounce rate, traffic source, etc.

No cookies to display.

Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.

No cookies to display.

Advertisement cookies are used to provide visitors with customized advertisements based on the pages you visited previously and to analyze the effectiveness of the ad campaigns.

No cookies to display.

Pages Menu
TwitterRssFacebook

Posted by on Jun 6, 2022 in Development, Microsoft Teams

Microsoft will start charging for some Microsoft Graph Teams API calls starting July 5th 2022

Microsoft will start charging for some Microsoft Graph Teams API calls starting July 5th 2022

We’ve known for some time that Microsoft have wanted to start charging for use of some parts of Microsoft Graph, their API platform for accessing Microsoft 365 services and data.

Back in October 2021, a set of APIs predominantly aimed at Export scenarios went from Beta to GA, and a new charging structure was announced. The structure itself is fairly complicated and depends firstly on whether the application making the API calls qualifies as a “Security and Compliance (S+C)” application.

According to the Commercial Licensing Terms:

“Compliance Application” means a software program or service built exclusively to ensure that an organization is complying with their security-related requirements.  

“Security Application” means a software program or service built exclusively to protect and defend the information and technology assets of an enterprise.  

At that time, no charging actually took place, mostly because there wasn’t a back-end infrastructure in place to process it. In October, I wrote:

However, if you think that your application might be impacted by these changes and charges then now is the time to start planning for what you do about that so that you (or your customers) are not negatively impacted when these charges start to roll out.

Me, October 2021

Fine, so what changed?

In a blog post this week, Microsoft announced that the new charging structure will go live on July 5th 2022 and from that point, qualifying API calls will be charged.

That means that, from July 5th you can expect to pay for use of these APIs, unless you’re covered by the S+C definitions and have the appropriate licenses, or your application risks being throttled. More details on all of this below.

Help! I have an app, what does this mean?

Firstly, does your app make any of the API calls impacted by this change? It can be easy to include one of the APIs without realising, but look for this message in the documentation:

At the time of writing, the affected API calls are:

If you are affected, the next step is to determine if you qualify as a Security & Compliance application, and if the tenant where the app will be run meets the license requirements of the API calls you are making. These vary by API (some require any user in the tenant to have the license, others require the user making the call to have the license). Consult this guide: model=a requirements. If you can, then you should use model=a, because there is a capacity of included APIs for model=a included with the required licenses that will reduce the overall cost.

Also, you need to make sure you specify which model you are using when you make the API call, either model a or model b. You do this via a URL parameter to the call, as shown below:

GET /users/{id | user-principal-name}/chats/getAllMessages?model=A
GET /users/{id | user-principal-name}/chats/getAllMessages?model=B

What do I need to do right now (and definitely before July)?

  1. Decide if you have a Security & Compliance application or not, and whether the tenant running your application has enough licenses
  2. Update your API calls to include the model=a or model=b parameter.
  3. Fill out this form which confirms you’re OK with being charged, and links the Application ID of your application with an Azure Subscription: Teams Protected API Azure registration (for me, when I published this, this form didn’t work – giving the error message “You don’t have permission to view or respond to this form”)
  4. Communicate this change to any non-technical account managers or others in your organisation, as there may be cost implications impacting either you or your customer (see below).

I have a multi-tenant app running in many tenants, who pays?

It’s a common scenario for multi-tenanted applications that an application is registered in the ISV’s tenant and permission is then granted by the customer tenant admin for that application to work in their tenant. This enables a single application to be able to work with data from a number of tenants through a single Application ID. The alternative is that every deployment needs to have an application created on the customer’s tenant, with permissions set up (usually manually), and the application ID and secret then shared with the ISV.

In the announcement this week though, Microsoft state: “These will be billed through an Azure subscription on the Azure tenant where the application requesting access is registered.”

For multi-tenanted applications, that means that the ISV is going to be picking up the cost of making these API calls.

As I see it, ISVs with multi-tenanted applications have 3 options for what they do here:

  • Soak up the consumption cost themselves,
  • Pass the cost onto the customer by firstly absorbing it through their application and then passing it on as an additional charge. This might be tricky if the software/service pricing has already been agreed.
  • Move to a single application per tenant model, thus ensuring that the cost automatically goes to the customer.

Regardless of the approach, there will need to be some discussion between ISV and customer over this for S&C applications, because the ISV will need to know whether the tenant qualifies for model=a (based on license usage) or not, but the tenant admin is responsible for ensuring license requirements are met.

How much will I be charged?

Charging is consumption based: the more you use, the more you pay. For qualifying S+C applications, there is an included number of messages: this varies by API. Consult the seeded capacity table for the full details.

For everyone else (or once the seeded capacity has been used) calls are charged, currently all at the same price: $0.00075 per message. This is subject to change, so be sure to continue to reference the Licensing and payment requirements page for the latest information.

As an example, for a 1000 person organisation where each user generates 100 chat messages a day = 100,000 messages per day = $75 per day to be notified about every chat message. To perform a one-time export of all chat messages in a week: 1000 x 100 x 7 = 700,000 = $525.

What if I ignore this / do nothing? Will I still be impacted?

Yes. If you choose to do nothing, and continue to make calls without specify either model=a or model=b you will not be charged. However, your API calls will be made in “evaluation mode”.

Evaluation mode is capped at 500 calls per app, per month across all APIs. When that limit is reached, further calls will return a 402 message. In addition, any change notifications which are set up (today, it’s just chat message change notifications which are affected) will stop sending notifications.

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.

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.

Share to Microsoft Teams