Microsoft 365 Copilot APIs - What They Are and When to Use Them

Most conversations I have about Microsoft 365 Copilot start the same way. Someone in IT or the business has rolled out a few hundred licences, people use it to summarise emails and draft documents, and then a sharper question lands on the table: "Can we use what Copilot knows inside our own apps?"

For a long time the honest answer was "sort of". You could build a declarative agent, you could write an API plugin, you could push data in through a Copilot connector. All of that is about getting things into Copilot. Getting Copilot's intelligence out, into your own line-of-business systems, was much harder.

The Microsoft 365 Copilot APIs change that. They sit in Microsoft Graph and expose pieces of the Copilot stack as plain REST endpoints. For Australian organisations that have already paid for Copilot licences and want more return from them, this is the part of the extensibility story I think deserves the most attention right now.

Here's how I'd explain it to a colleague, along with what we've seen work and where it still feels unfinished.

Two directions of extensibility

It helps to split Copilot extensibility into two directions.

Inbound is everything that extends Copilot itself. Declarative agents, API plugins, Copilot connectors, custom engine agents built with Copilot Studio or the Microsoft 365 Agents SDK. Users stay inside Copilot Chat or Teams, and you're adding knowledge or actions to that experience. We've written about this side a fair bit, including our earlier overview of Copilot extensibility.

Outbound is the Copilot APIs. Your app calls Graph, and Graph hands back something Copilot has done: grounded retrieval results, a chat response, meeting notes, an export of interactions. The user might never open Copilot at all. They're in your CRM, your claims system, your internal portal, and Copilot is doing work behind the scenes.

That second direction is what Microsoft's Copilot APIs overview covers, and it's a different design conversation from building agents.

What's in the box

The API family has grown steadily. At the time of writing, these are the ones I'd pay attention to:

Retrieval API. This is the one most teams want first. You send a natural language query, and it returns relevant text chunks from SharePoint, OneDrive and Copilot connector content, trimmed to what the calling user is allowed to see. It's basically the semantic index behind Copilot, exposed so you can do retrieval augmented generation with your own model and your own prompt. No need to copy documents into a separate vector store.

Chat API. Lets you have a multi-turn conversation with Copilot programmatically, grounded in the user's work data and optionally the web. Useful when you want Copilot's full reasoning and grounding, not just retrieval chunks, inside your own UI.

Search API. Hybrid semantic and keyword search across OneDrive content (with more sources promised). Think of it as "find me the documents about X" rather than "give me passages to feed a model".

Meeting insights API. Pulls the AI-generated notes, action items and mentions out of Teams meetings that were recorded and transcribed. We've had a lot of interest in this from professional services firms who want meeting outcomes to flow into their practice management systems without someone retyping them.

Interaction export and change notifications. These are for compliance and governance teams. You can export the prompts and responses users have exchanged with Copilot, and subscribe to notifications when new interactions occur. If you're in financial services or government and someone has asked "how do we audit what people are asking Copilot?", this is the answer.

Some of these are generally available and some are still in preview. Check the docs for current status before you build anything a business depends on, because preview APIs in Graph do change shape.

Why the Retrieval API matters so much

I want to spend a bit more time on retrieval, because it's the one that changes project economics.

On a typical RAG project in the past, a large chunk of our effort went into plumbing. Crawl SharePoint, extract text, chunk it, embed it, store it in Azure AI Search, then rebuild the permission model so a junior analyst doesn't get answers sourced from the board pack. That permission work is the bit that keeps security teams up at night, and it's easy to get subtly wrong. A document gets reshared, your index doesn't notice, and now you have a leak.

With the Retrieval API, Microsoft handles all of that. The content is already indexed for Copilot. Permissions are evaluated at query time against the real ACLs. You call the endpoint with a delegated token for the user and get back passages they're allowed to see. Then you pass those passages to whatever model you like, whether that's Azure OpenAI, a model in Azure AI Foundry, or Claude.

We recently scoped a policy assistant for a mid-sized insurer. The original estimate with a custom ingestion pipeline was around eight weeks. Using the Retrieval API for the SharePoint content brought the core build down to about three, and the security review was far shorter because there was no second copy of the data to worry about.

That said, it's not a drop-in replacement for a custom index in every case. A few things to know:

• You get what the semantic index gives you. You don't control chunking, embedding model or ranking. For most document collections that's fine. For highly structured content like product catalogues or tables, a purpose-built index can still do much better.
• It's scoped to Microsoft 365 content. If half your knowledge lives in a ticketing system or a SQL database, you'll either need Copilot connectors to bring it in or a hybrid approach that queries multiple sources.
• Filtering is limited. You can scope by site and use some metadata filtering, but it's not as flexible as writing your own filter expressions against a search index.

Licensing and cost - read this before you get excited

This is where projects stall, so I'll be blunt.

The Copilot APIs are built on the assumption that users have Microsoft 365 Copilot licences. Several of them simply won't return results for unlicensed users. If your plan is "license 50 power users and expose the Retrieval API to 2,000 staff through our intranet", go and read the current licensing terms carefully and talk to your Microsoft account team. Microsoft has been experimenting with pay-as-you-go options for some scenarios, and the rules have shifted more than once.

For organisations that have already licensed broadly, this is good news. You've paid for the semantic index and the grounding, and the APIs let you use that investment in more places. For organisations that bought a pilot batch of 25 licences, the APIs probably won't change your business case much yet.

There's also throttling. These are Graph endpoints with Graph-style limits. For a single user's interactive app that's not an issue. For a batch job that wants to run 10,000 retrieval calls overnight, it might be.

What we've seen work

A few patterns keep coming up.

Copilot inside existing systems. Staff don't want another chat window. A case management screen that shows "relevant policies and past precedents" pulled through the Retrieval API, with a short summary generated by your own model, gets used far more than a separate Copilot agent people have to remember to open. We see this a lot in professional services and insurance.

Meeting outcomes into workflow. Meeting insights feeding action items into Planner, a CRM or a project tool. Simple, valuable, and it doesn't need much AI cleverness on your side because the notes are already generated.

Governance reporting. Interaction export into a compliance store or Microsoft Purview workflows, with dashboards showing which teams are using Copilot and for what. Boards and risk committees like this, and it helps answer the "are we getting value from these licences?" question with data instead of anecdotes.

Custom agents with better grounding. If you're building an agent in Azure AI Foundry or with the Microsoft Agent Framework, the Retrieval API can be one of its tools. The agent decides when it needs internal documents, calls retrieval, and reasons over the results. This is where the APIs and the agent work meet, and it's the area our Microsoft AI consultants are spending the most time on.

What's still rough

I don't want to oversell this. A few honest gripes:

• Preview churn. Some endpoints have moved between beta and v1.0, changed request shapes, or added required parameters. Build with an abstraction layer so you're not rewriting call sites across your codebase when that happens.
• Delegated permissions only, mostly. Many scenarios need a signed-in user. That's correct from a security standpoint, but it makes background processing awkward. If you want an overnight job to process documents, you'll need to think about which APIs support app-only access and which don't.
• Debugging relevance is hard. When the Retrieval API returns something odd, you have limited visibility into why. With your own index, you can inspect scores and tune. Here, your main lever is improving the content itself, which honestly is often the real problem anyway.
• Documentation is spread out. Between Graph docs, Copilot extensibility docs and licensing pages, you'll be jumping between a lot of tabs.

Where to start

If you're an organisation with Copilot already rolled out and you're wondering whether the APIs are worth exploring, here's the order I'd go in:

1. Pick one internal app where people regularly go hunting for documents. Prototype the Retrieval API against it with a handful of licensed users. You'll know within a week or two whether the relevance is good enough.
2. Check your SharePoint hygiene. Retrieval quality depends heavily on whether your content is current, well named and properly permissioned. Old drafts and duplicated "FINAL v3" files hurt results.
3. Talk to your compliance team about interaction export early. It's often the easiest win politically, because it addresses concerns they already have.
4. Confirm licensing for your target user base before you design anything big.

If you'd like help figuring out whether the Copilot APIs, a custom Azure AI build, or some mix of the two fits your situation, our Copilot Studio and Copilot extensibility team does this work every week. My general view is that the outbound APIs are where Copilot starts becoming part of the platform rather than just another chat app, and the organisations that work that out early will get a lot more value from the licences they've already bought.