The new Meeting AI Insights API is nice … but there’s a big problem

As I spoke about this morning in my weekly update video, there’s a new Microsoft Graph API out, on the beta endpoint. It’s the “Meeting AI Insights” API, and it allows you to get insights from transcribed Microsoft Teams meetings.

This includes a summary of the conversation, any action items that were identified, and any “mention events” where a participant was identified.

So far, so good – and I’m sure a lot of you that already work with meetings are getting excited about how you can access this rich data, from only a meeting ID. There are some caveats at the moment (only for scheduled meetings, not channel meetings, not expired meetings etc), but there’s clearly potential here. In fact, the Microsoft Learn page suggests some use cases for this API:

Use case	Scenario	Integration	Impact
Autogenerate meeting summaries for CRM updates	A sales team conducts regular customer meetings over Teams. After each call, they need to log meeting summaries and follow-ups in their CRM.	After each meeting, you can have a backend service listen for meeting end events and use Microsoft Graph APIs to fetch post-meeting insights. The service extracts summaries and action items, and maps them to specific fields in the company’s CRM records. Optionally, the integration can include a Teams message card confirming the update.	– Saves time for sales representatives by eliminating manual entry. – Ensures consistent capture of key details across all customer interactions.
Capture post-meeting knowledge in a project management app	Product and engineering teams hold regular meetings to make design and feature decisions. Team members often forget to document what was discussed and agreed upon.	You can use a bot or a background job to query the Graph API for concluded meetings owned by product leads. The API fetches insights and uses natural language processing (NLP) to classify them, such as decisions, tasks, or risk items. These classifications are converted into tasks or notes in Azure DevOps, Jira, or Notion and assigned to the correct stakeholders using Graph user identities.	– Prevents information loss. – Automatically bridges the gap between conversation and task tracking. – Promotes alignment and accountability.
Generate executive briefings for strategic meetings	Executives participate in multiple high-level meetings across functions such as finance, operations, or board reviews. They need quick, reliable summaries to stay up-to-date and take action.	You can create a digital assistant to call the Graph API after the designated executive meetings conclude to retrieve insights, prioritize key decisions and blockers, and format them into a concise daily briefing card. This card is posted to the executive’s Teams chat or sent as a morning email summary. The integration can optionally highlight recurring themes using keyword clustering across meetings.	– Improves executive focus and decision velocity. – Reduces reliance on manual note-taking and follow-ups. Enables faster cross-functional awareness.

So, what’s the problem?

The problem is that this API call only works with delegated permissions, not application permissions. That means there has to be a user present, logged in and clicking the buttons.

Look at those use cases again, specifically the Integration column. Notice some key words:

• back-end service
• bot or background job
• digital assisant

All of these would require application permissions. Further, the Learn page warns that AI-generated insights “might take up to four hours” to be available. That’s fine for a back-end service that can poll and wait for them, but it’s no good for something that a user has to do.

Why?

So why is this like this? Why build such a useful API endpoint, and then not make it usable by the very set of applications that would benefit from it?

I don’t know, but I can guess. It’s because of this prerequisite: The user that calls this API must have a Microsoft 365 Copilot licence.

With that restriction in place, making this API use only delegated permissions means enforcement is easy. Enforcing that rule for application permissions is hard, possibly impossible, or requires a different compensation structure, similar to the model=a,b payment models used by other Graph endpoints.

I hope Microsoft find a way around this non-technical limitation, because this API endpoint would be really useful for loads of use cases and for ISVs building solutions that work with Microsoft Teams meetings. But, lots of them aren’t going to be able to use, which is a shame.