Microsoft Copilot API: What the Official APIs Return vs Scraping

Is there a “Microsoft Copilot API”?

Most developers expect the wrong thing here. When someone asks for “the Microsoft Copilot API,” they usually picture an OpenAI-style endpoint that takes a prompt and returns Copilot’s answer. That single, public endpoint simply does not exist today.

What exists instead is a family of enterprise APIs. At Build 2025, Microsoft launched the first wave of Microsoft 365 Copilot APIs, a lineup of five: Interactions Export, Change Notifications, Meeting Insights, Retrieval, and Chat. Every one is reached through REST under the Microsoft Graph /copilot/ namespace and authenticated with Microsoft Entra ID.

The framing on that launch is blunt, and it shapes everything else. Microsoft states these APIs are “only available for Microsoft 365 Copilot licensed users,” and they run entirely within the Microsoft 365 trust boundary. So a Microsoft Copilot API, in the official sense, is an enterprise extensibility tool rather than a window into the public web.

That distinction drives every section below. The official APIs help you build agents grounded in your organization’s own content and permissions. They were never designed to report on the consumer Copilot answer that a stranger sees.

The five APIs and their launch status

The APIs shipped at different maturity levels, and that difference still matters. Interactions Export, Change Notifications, and Meeting Insights entered public preview at Build, and the Retrieval API followed shortly after in public preview. The Chat API began as a private preview and remains a preview surface documented under the Graph /beta version.

Preview status is not a footnote you can ignore. It means the terms of use, endpoints, and limits can all change before general availability. Treat any Microsoft Copilot API integration as a moving target until Microsoft marks it generally available.

What the official Copilot APIs return

Three of the five APIs are the ones most developers actually reach for. Here is what each one hands back, and just as importantly, where each one stops.

The Chat API — synthesized, grounded answers

The Microsoft 365 Copilot Chat API is the closest thing to the endpoint people imagine. It lets you “programmatically engage in multi-turn conversations with Microsoft 365 Copilot while using enterprise search grounding and web search grounding.” You hand it a prompt, and it hands back a fully synthesized answer.

The appeal is that you skip the plumbing entirely. Microsoft’s docs put it plainly: you “don’t need to egress data, break permissions, or compromise on security and compliance.” You also avoid building your own vector index, large-language model, and orchestration layer, because this Microsoft Copilot API does the grounding and synthesis inside the tenant.

Mechanically, you work with it as a conversation over two Graph calls. You first create a conversation with POST /beta/copilot/conversations, which returns a 201 Created and a conversation ID. You then continue it against the synchronous endpoint, which returns the full reply in one 200 OK response. A streamed endpoint returns server-sent events with a text/event-stream content type for progressive rendering.

Access is narrower than many teams assume going in. The Chat API supports delegated (work or school) permissions only, and application permissions are not supported at all. Its least-privileged delegated scopes include Sites.Read.All, Mail.Read, and People.Read.All, and today the endpoint is limited to the global Microsoft cloud. It is not available in the US Government or China-operated deployments.

Grounding gives you a useful amount of control on each message. You can supply OneDrive and SharePoint files as context, and you can toggle web search grounding on or off. Note that toggling web search off is a single-turn action, so you must disable it again on every message where you don’t want it.

What the Chat API deliberately does not do is the most telling part. It “only responds with textual responses,” so it never creates files, sends emails, or schedules meetings. It has no code interpreter, no graphic-art tool, and no support for long-running tasks, which are prone to gateway timeouts. This is an answer engine bounded by your tenant, not a general-purpose agent.

Compliance is the quiet selling point of this endpoint. Because the Chat API uses Microsoft 365’s built-in security and compliance features, data-source permissions and compliance settings are preserved on every call. Sensitive content from one user is never exposed to another, and answers stay grounded in the enterprise search index rather than a stale copy.

The response is also richer than plain text under the hood. Each reply comes back as a copilotConversation whose messages can carry attributions — annotations and citations that point back to the grounding source, such as a SharePoint file or a Teams event. Messages also carry a sensitivityLabel, so the tenant’s information-protection markings travel with the answer.

The Retrieval API — permission-trimmed text chunks

The Microsoft 365 Copilot Retrieval API is the RAG primitive rather than an answer engine. Instead of synthesizing a reply, it returns “relevant text chunks from the hybrid index that powers Microsoft 365 Copilot.” You then feed those chunks to your own model for generation.

That hybrid index is Copilot’s semantic index, a combined lexical and semantic map of your organization’s data in Microsoft Graph. The chunks it returns come from three data sources: SharePoint, OneDrive, and Copilot connectors. Every result is permission-trimmed, so a user only ever sees content they are already allowed to access. That trimming is the whole reason to reach for this Microsoft Copilot API instead of a homemade index.

You can scope a retrieval with Keyword Query Language (KQL). A filterExpression lets you filter by URL, date range, file type, and more. If your KQL syntax is wrong, the query still runs and simply returns unscoped results, which is an easy failure mode to miss.

The response is shaped by hard limits worth knowing before you build. The queryString caps at 1,500 characters and should be a single sentence, maximumNumberOfResults caps at 25, and you get up to 200 requests per user per hour. Each extract carries a relevanceScore, defined as “the cosine similarity between the queryString and the extract, normalized to the 0-1 range.”

Content limits apply on top of those quotas. Retrieval from tables is limited to .doc, .docx, and .pptx files, and images and charts are not supported at all. Files over 512 MB for .docx, .pptx, and .pdf, or 150 MB for other types, are skipped entirely. This is grounding data for your own model, not finished prose.

Access needs the right Graph scopes, and getting them wrong returns nothing useful. SharePoint and OneDrive retrieval require Files.Read.All and Sites.Read.All, while Copilot connector retrieval requires ExternalItem.Read.All. Those scopes are how this Microsoft Copilot API inherits the tenant’s existing security model.

Two design choices from Microsoft’s guidance matter in practice. Keep each queryString to a single, context-rich sentence, and avoid generic queries that could match a wide range of content. Microsoft also recommends sending every returned extract to your model, rather than trimming the result count, unless your own token budget forces the issue.

The filtering is what makes this API viable for regulated work. Finance and legal apps can scope a filterExpression to specific document libraries or content types, so answers only ever draw on approved sources. Multi-source apps can combine SharePoint and OneDrive content with Copilot connector data, building one governed knowledge base that spans Microsoft 365 and third-party repositories.

Export, Change Notifications, and Meeting Insights — the audit layer

The remaining three APIs round out compliance and analytics, and each describes activity inside your tenant. They live under the same Graph /copilot/ namespace, where the interaction history and admin controls sit as related resources.

The Interactions Export API exports Copilot interactions — prompts, responses, and metadata — for auditing, compliance reporting, and usage analytics across surfaces like Teams and Outlook. Change Notifications let you subscribe to those interactions in near real time, so you get updates without repeatedly polling the API. Meeting Insights returns AI-generated summaries, action items, and decisions from Teams meetings, built for follow-up automation and CRM enrichment. All three run under the same identity and governance controls, and none of them touch the public web.

Getting started with the Copilot APIs

Every call goes through Microsoft Graph on the /beta version for now. You register an Entra ID app, request the delegated Graph scopes, acquire a token, and call a path under /copilot/. That flow is broadly consistent across each Microsoft Copilot API in the family.

You can also try before you write any code. Graph Explorer supports the synchronous Chat and Retrieval calls, though streamed conversations are not supported there, and Microsoft ships an interactive Retrieval demo. Both let you inspect a live request and response against your own Microsoft 365 data.

One gate applies to everything on this surface. By using any of these endpoints, you agree to the Microsoft 365 Copilot APIs preview terms of use. Read them carefully before you build a production integration on a preview API.

The catch: tenant-scoped, license-gated, enterprise-only

Read those sections together and the pattern is unmistakable. Every official Microsoft Copilot API shares four traits: it is scoped to your Microsoft 365 tenant, gated behind a Copilot license, authenticated through Entra ID with specific Graph scopes, and grounded in your organization’s own data.

Licensing has exactly one partial exception worth flagging. The Retrieval API offers pay-as-you-go consumption for users without a Copilot add-on license, billed at $0.10 per API call. That option covers tenant-level sources only, meaning SharePoint and Copilot connectors, while user-level sources such as OneDrive are excluded, and it remains a preview feature.

That model is exactly right when you build an internal agent over corporate knowledge. It is exactly wrong when your question is about the public web instead.

What the official APIs don’t return

Here is the gap that trips people up. “Microsoft Copilot” is really two products: the enterprise Microsoft 365 Copilot that these APIs serve, and the consumer Copilot at copilot.microsoft.com that anyone can use for free.

No official Microsoft Copilot API lets you query that consumer surface. There is no endpoint that returns the rendered public answer, with the web sources and citations a public user actually sees. The APIs report on your tenant’s private activity, and they don’t expose the public-facing answer surface at all.

So one very common question has no API answer. When a stranger asks Copilot about your category, what does it say, and does it cite you? None of the five APIs can tell you, because that is a monitoring problem rather than an extensibility one.

Which Copilot API should you use?

Match the API to the job, and the choice gets simple.

• Building an agent over tenant data? Use the Chat API for synthesized replies, or the Retrieval API for raw chunks you feed to your own model.
• Feeding an existing LLM with grounded context? The Retrieval API is the RAG primitive built for exactly that.
• Auditing or reporting on Copilot usage? Interactions Export plus Change Notifications cover the compliance surface.
• Automating meeting follow-ups? Meeting Insights returns the summaries and action items you need.
• Measuring what consumer Copilot tells the public? No official Microsoft Copilot API fits, so you need the rendered consumer surface instead.

The first four are extensibility jobs that live inside your tenant. The last one is a visibility job, and it sits entirely outside the official API.

Scraping consumer Copilot — when you actually need it

For brand and citation monitoring in AI search, the public answer is the whole point. Capturing it means working with the rendered consumer surface rather than an API, and that is the exact problem cloro’s how-to-scrape-Copilot guide walks through.

The goal is to capture what a real user actually sees. That includes the consumer Copilot answer, its web-grounded citations, and the source metadata behind each one. None of that data is exposed by any official Microsoft Copilot API.

The trade-off is straightforward once you name it. Use the official APIs when you build enterprise agents over your own tenant data, and use a scraped consumer surface when you measure what Copilot tells the public. That second job is exactly what AI visibility tracking requires.

Where cloro fits

cloro sits firmly on the monitoring side of that line. It captures the consumer Copilot answer and its citations as structured data, which is the same surface the official APIs never expose. One endpoint covers Copilot alongside ChatGPT, Perplexity, Gemini, and Google’s AI surfaces, so you can compare visibility across engines from a single feed.

If you’re deciding between wiring up the Microsoft Copilot API family and monitoring public AI answers, they solve genuinely different problems. The APIs are for building on your tenant, while a managed scraper is for measuring the public web. For the Copilot-side implementation details, the Copilot scraping guide has the full walkthrough.

Conclusion

“Is there a Microsoft Copilot API?” has a more interesting answer than most people expect. The official APIs are real, powerful, and well-documented, but they are enterprise extensibility tools that are licensed, tenant-scoped, and grounded on your organization’s data.

What they never return is the public Copilot answer that everyone else sees. So the right tool depends entirely on the job at hand. Build with the Microsoft 365 Copilot APIs when you work inside your tenant, and capture the consumer surface when you need to know what Copilot tells the rest of the world.