Calling Microsoft 365 Copilot From Your Own Code - The Chat API and Work IQ
For most people Copilot is a box you type into inside Word or Teams. You ask a question, it answers, and the whole interaction lives inside a Microsoft app. What a lot of teams have not clocked yet is that the same engine is reachable from code. You can send a prompt to Copilot from your own application, and it will answer using your organisation's knowledge, the same knowledge it draws on when someone chats with it in the Microsoft 365 app. That is what the Chat API in the Copilot extensibility stack does, and it changes the shape of what you can build.
The mechanism sits under something Microsoft calls Work IQ, which is the layer that understands your organisation's people, files, meetings, messages and the relationships between them. When you call the Chat API you are not just hitting a generic language model. You are hitting one that already has your tenant's context wired in. That distinction is the whole point, and it is worth being clear about before you decide whether this belongs in your project.
What the Chat API actually gives you
Strip away the branding and the Chat API is a request-response endpoint. You send a conversation, which is a prompt plus optionally the history of what has been said so far, and you get back a grounded answer. The grounding is the interesting bit. The response can pull from the documents, emails, chats and calendar items the calling user has access to, so an answer to "what did we agree with the Northbridge council on the retaining wall" comes back with the actual context from the actual thread, not a generic guess.
Because it is a conversation, you can keep the thread going. Send a follow-up, include the prior turns, and Copilot treats it as a continuing discussion rather than a cold start each time. That matters for anything that feels like an assistant rather than a one-shot lookup. A support tool that lets a staff member ask three or four connected questions about an account needs that continuity, and the API carries it for you rather than making you rebuild conversation state from scratch.
The other thing you get, which people underestimate, is that the permission model comes along for the ride. The answer respects what the user is allowed to see. If someone calls your app and they do not have access to a particular SharePoint site, the Copilot response grounded through Work IQ will not reach into that site on their behalf. You are not building a back door. You are building a front end onto the same access rules that already govern the user.
Where this is genuinely useful
The pattern I keep coming back to with clients is the internal app that needs Copilot's intelligence but should not send people off to a separate Copilot window to get it. Think of a claims system, a project portal, a customer service desktop. The staff member is already in the tool where the work happens. Breaking their flow to go and ask Copilot something in Teams, then copy the answer back, is friction that kills adoption. Calling the Chat API from inside the app means the intelligence shows up where the work already is.
A financial services client we worked with had a case-management app their advisers lived in all day. The advisers kept alt-tabbing to Copilot to ask things like "summarise the last three interactions with this client" and then pasting the result into their notes. Wiring the Chat API into the app directly meant the summary appeared in context, grounded in the actual email and meeting history for that client, with a button instead of a tab-switch. Same intelligence, none of the hopping about. That is the whole game with this API: it lets you put Copilot where your people already are rather than dragging them to where Copilot lives.
The second pattern is automation that needs judgement. Plenty of business processes have a step that a rules engine cannot handle because it needs someone to read a pile of context and make a call. A prompt to the Chat API, grounded in the relevant organisational data, can draft that call for a human to approve. Not replace the human, draft for them. Triage an inbound request, suggest which team it should go to based on what similar requests went to before, flag the ones that look unusual. This is the sort of thing our AI automation work often lands on, because the value is in the boring middle of a process, not the flashy front of it.
The parts that are still rough
I will be honest about where this gets awkward, because the demos never show you this part.
The first thing is that grounding quality is only as good as the underlying data hygiene, and most organisations' data hygiene is worse than they think. If your SharePoint is a swamp of duplicated documents with three versions of the same policy and no clear source of truth, Copilot grounded on that swamp will give you confident answers built on the wrong version. The API does not fix your information architecture. It exposes it. We have had more than one project where the real work turned out to be cleaning up the data estate before the Chat API could give answers anyone would trust. That is not a criticism of the API. It is just the reality that grounded AI makes your data quality suddenly very visible.
The second is latency and cost at scale. A single grounded chat call does real work behind the scenes, retrieving context and reasoning over it. That is fine for a user clicking a button and waiting a second or two. It is less fine if you wire it into a high-volume automated loop that fires thousands of times an hour, both for the wait and for the consumption. You need to think about where a grounded Copilot call is worth it versus where a cheaper, narrower approach does the job. Not every step in a process needs the full organisational-context treatment, and treating the Chat API as a hammer for every nail gets expensive.
The third is that this is a moving target. The extensibility surface across Copilot, Work IQ and the various APIs is still settling, and things that are in preview shift. If you build on it, build with the assumption that some of the plumbing will change under you over the next year. That is not a reason to avoid it. It is a reason to keep your integration layer thin and well contained so a change upstream does not ripple through your whole application.
How to think about whether you need it
The question I ask clients is simple. Do you need Copilot's intelligence somewhere that is not a Microsoft app? If the answer is yes, and you need it grounded in your own organisational data with the user's permissions respected, then the Chat API is the right tool and there is not really a shortcut around it. If what you actually need is a standalone assistant with no particular tie to Microsoft 365 content, you might be better served by building directly on a model API where you control the grounding yourself, which is the sort of custom build our AI agent builders team does when the Microsoft context is not the centre of gravity.
The line between those two is worth getting right before you commit, because they lead to quite different architectures. Grounding through Work IQ is a genuine advantage when your value lives inside Microsoft 365, and a needless dependency when it does not. I have seen teams reach for the Copilot API out of familiarity when a simpler build would have served them better, and I have seen teams build a whole custom retrieval pipeline when Work IQ would have handed them the grounding for free. Picking the right one is most of the decision.
Where we come in
The build itself, once you have decided, is not the hard part. Authenticating the call, passing the conversation, handling the response, respecting the permission boundaries, all of that is tractable engineering. The hard part is the design decision underneath it: what should be grounded, where the intelligence belongs in the workflow, and whether the data behind it is clean enough to trust. That is the conversation we tend to have first with clients through our Microsoft AI consultants practice, before anyone writes a line of integration code.
If you have got an internal application that would be better with Copilot's intelligence wired into it, or you are weighing up whether to build on the Copilot extensibility stack versus a custom approach, that is squarely the kind of decision we help teams get right. Take a look at our business AI services or get in touch and we will work through where the Chat API fits and where it does not.