Working with Microsoft 365’s new Copilot APIs

Microsoft has been adding AI features to its Microsoft 365 productivity platform for some time now, even renaming its desktop Office portal app “Microsoft 365 Copilot.” Under the hype is a mix of useful tools that gives you new ways of working with enterprise content.

That’s not surprising, considering that much of Microsoft 365 has been built on Microsoft’s existing enterprise content management platform, SharePoint. It’s an ideal foundation for AI tools as it offers role-based access to a mix of structured and unstructured data, all stored in hierarchical user- and team-defined repositories. That data helps ground large language models (LLMs) too, providing the necessary framework for retrieval-augmented generation (RAG) and other orchestration techniques.

Having a ground truth for Microsoft 365’s Copilot helps reduce risks associated with Microsoft’s AI applications, but that still limits what can be done with the services Microsoft has been building, especially when we want to build them into our own applications and workflows. With the increasing importance of agent-powered workflows in business process automation, having access to the Microsoft 365 Copilot platform would help speed up application development.

It’s clear there is not a one-size-fits-all approach to AI applications. Microsoft’s various Copilots only go part of the way to supporting businesses, with much more of a focus on the individual user. But Microsoft is a platform company, and eventually what it builds for its own applications becomes another piece of their developer story.

Introducing the Microsoft 365 Copilot APIs

It was good to see the announcement of a series of Microsoft 365 Copilot APIs at Build 2025, breaking out key pieces of its functionality while maintaining the essential security needed to build AI applications that comply with appropriate regulations and ensure only authorized users have access to data. Five different APIs are in the first set: Retrieval, Interactions Export, Change Notifications, Meeting Insights, and Chat. The first four are available as public previews, and the Chat API is currently in private preview.

Retrieval and Interactions Export are the APIs likely to be of most interest to anyone building AI workflows around Microsoft 365. Public previews are intended to test new code, as there can be breaking changes between releases, and so they are only available through the Microsoft Graph’s beta endpoint. Like all Microsoft Graph APIs, if you have the right tenant permissions, you can use the web-based Graph Explorer to build and test Copilot API requests.

Using the Interactions API for compliance

The Interactions API fills an interesting gap, as it builds on existing Teams compliance tools to use the Microsoft 365 Graph to download user interactions for analysis. The outputs include the initial user prompt and the response from the service—not only from the standalone Copilot app, but also from inside tools such as Word and Outlook.

The Interactions API isn’t a compliance tool, but it can be used to build one, offering a way to see prompts and responses that have been used in the Microsoft 365 Copilot. It helps find common prompts, allowing you to build them into Teams applications or Office plug-ins. The resulting prebuilt prompts can then be watched to ensure there’s minimal output drift or that updated content added to Microsoft 365 doesn’t distort responses. If users are using prompts where there’s no data, you can use this as a signal to create content or add sources.

Access is via a familiar HTTP call to the Copilot graph endpoint. You can get the entire interaction history for your organization in one call or you can apply filters to bring in a subset of the data. For example, you can filter by date or user ID. With a standard Microsoft Graph call structure, you have access to all the filter statements you’ve used in other applications, as well as basic Booleans and SQL-like queries.

Regular sampling of queries and responses can watch for leaks of personally identifiable information, as well as ensure that users’ role-based access controls only give access to authorized data. You can chain queries, using data from one to drive another, for example, a Microsoft Graph query can first get a user ID from an email address before querying to see how they are using Copilot in Word.

Responses are returned in JSON format, and you can use the Microsoft Graph SDK to build and parse requests. Alternatively, tools like Kiota generate libraries for specific endpoints, giving you the tools to build your own Copilot usage analytics applications and dashboards.

Ground your AI applications with enterprise data

The latest endpoint to get a public preview is the Retrieval API, which simplifies the process of bringing your enterprise content—and the resulting enterprise knowledge—into your AI applications using tools like Semantic Kernel or Copilot Studio. Like the other APIs, it’s designed to work inside the Microsoft Graph security perimeter, ensuring that users get answers based on their own authorizations.

You can use the API to build AI applications without adding complexity; there’s no need for vector indexes or a separate query environment. Instead, you build on Microsoft’s own semantic index, which powers the enterprise search features built into the platform. This reduces the workload needed to build RAG connections, so you can concentrate on the content you want to surface in your applications without having to spend time thinking about nearest-neighbor search algorithms.

By building on the Microsoft Graph’s SharePoint heritage, you’re able to quickly surface relevant content, reducing the risk of generating hallucinations and errors by focusing operations on specific content and in specific domains. An AI application for the legal team can build on data in the libraries and lists they use, while the sales team will be able to work with historical bids and terms.

Like other Microsoft Graph calls, the retrieval API uses HTTP calls with requests embedded in the JSON body of a POST. This includes a query string of up to 1,500 characters, a list of SharePoint or connector data sources, as well as Kusto Query Language (KQL) format filters, and the required number of results. Filters are a powerful tool to choose documents with specific metadata, for example, from a single author or associated with a specific project or customer. Filter expressions use KQL and work with any document property.

Responses are returned in a JSON document. This holds links to source documents along with relevant text extracts. You can define the metadata that’s returned, too, for example, providing any sensitivity labels. The same procedure works for SharePoint and for Copilot connectors to external data sources, so you can bring in data from tools like ServiceNow or Jira. Working with connectors helps bring in other knowledge sources and allows you to tie agent workflows to service tickets and the like. Filters can target specific sites and services, locking down to one or selecting several sources.

One useful aspect of the retrieval API is its support for JSON batching. A single call can embed multiple queries, up to 20. This approach allows you to mix SharePoint and connector queries in a single call, as well as different permutations of the same query. Requests are given separate IDs, and responses are assigned to the same IDs. If you’ve used Microsoft Graph, this approach will be familiar, as it uses the existing JSON batch feature.

Build queries in C#

If you don’t want to handcraft API calls, Microsoft is developing an open source client library with versions for C#, TypeScript, and Python. Current versions of all three are available on GitHub, where you can report any issues. They will eventually be part of the Microsoft 365 Agents SDK and will be available via NuGet. The current beta release of the.NET tool can be installed via NuGet using the.NET CLI or PowerShell.

Once installed, the client library works with Azure’s identity provider to authorize access to the Microsoft Graph. You can define tenants, data sources, and query strings. The response will be stored in a Results object and can then be read back and used as needed. You can use that data as part of an LLM orchestration with your choice of tools.

Using data stored in the Microsoft Graph to both ground and personalize your AI applications makes a lot of sense. SharePoint has long been a place where libraries and lists let us structure unstructured data, while OneDrive is an often-overlooked source of corporate knowledge. Combining these new APIs with LLM orchestration should provide both essential security and effective grounding, using your own data to power agents and conversational user interfaces.