Integrating Copilot Studio agents with external APIs

A Copilot Studio agent that can only read a knowledge base is a search box with better manners. The agents that earn their place are the ones that do things: check an order status in a logistics system, raise a ticket in an external help desk, look up a price in a pricing engine, book an appointment. All of those live behind APIs that are not Microsoft's. Copilot Studio has accumulated four ways to reach them, and they are not interchangeable.

The four routes

REST API actions from an OpenAPI specification. You upload or point to an OpenAPI (Swagger) document, pick the operations to expose, describe each in plain language, and the agent can call them directly. The orchestrator decides when to invoke an operation based on the description and the user's request, fills the parameters from conversation context, and works the response into its reply. This is the most direct route and the one to try first for any API that has a decent OpenAPI file.

Custom connectors. The same Power Platform custom connector you would build for Power Automate or canvas apps, surfaced to the agent as an action. Worth it when the connector already exists, when you want the API reused across flows and apps, or when the API needs authentication types the REST action route does not handle well. See custom connectors in Power Platform.

Power Automate flows as actions. The agent calls a flow, the flow does whatever it likes, including multi-step logic, and returns outputs. This is the route for anything that is not a single API call: check two systems and combine, apply business rules, write an audit record. It adds latency and a flow run per invocation, and the flow becomes the thing you debug.

MCP servers. Model Context Protocol is the open standard for exposing tools to AI agents. Copilot Studio can connect to an MCP server and pick up all the tools it advertises at once, with their descriptions and schemas, instead of you defining each action by hand. If your organisation or a vendor already publishes an MCP server, this is the least work and the most likely to keep up with API changes. It is newer than the other routes, and the tooling around authentication and governance is still settling.

Choosing between them

Start with the question "is this one API call or a process?" One call: REST action or MCP tool. A process: Power Automate flow. Then ask "does this API already have a connector or an MCP server?" If yes, use it rather than describing the same endpoints again.

Custom connectors are the middle option that many teams skip straight past, and that is often correct. Their advantage is reuse; if the agent is the only consumer, the extra artefact is not worth maintaining.

Descriptions are the interface

The agent's orchestrator decides which action to call based on the natural-language descriptions you give each action and parameter. A vague description ("gets data") leads to the wrong action being called or never being called. A precise one ("returns the shipping status and expected delivery date for a sales order given its order number") gets used correctly. Spend real time on these, test with the phrasings users actually use, and treat description changes as releases.

Parameter descriptions matter just as much. If a parameter is an order number in a particular format, say so; the agent will otherwise pass whatever the user typed.

Authentication

This is where external API integration gets serious. The options are none, API key, OAuth 2.0 with a shared application identity, and OAuth 2.0 with per-user identity. For internal APIs behind Entra ID, per-user authentication is the right default because the external system then applies its own authorisation to the actual user rather than to a service account with broad rights. For third-party SaaS APIs with an API key, store the key in the connection, never in a topic variable, and rotate it like any other secret. See Dataverse secrets and Key Vault for where secrets should live.

Agents published to Teams and Microsoft 365 Copilot use the signed-in user's identity, which makes per-user auth straightforward. Agents published to a public website need to authenticate the user first before per-user auth means anything.

Error handling and fallbacks

External APIs fail, time out, and return shapes the agent does not expect. Configure what the agent says when an action fails, and make it honest ("I could not reach the order system just now") rather than inventive. For flow-backed actions, handle errors inside the flow and return a clean status rather than letting the run fail. For anything financial or irreversible, put a confirmation step in a topic before the action executes; the orchestrator should not book, pay, or delete on its own inference.

Governance

Every route passes through Power Platform DLP policies. A connector or an HTTP endpoint blocked by DLP will fail at design time or run time depending on the route, and the error is not always obvious. Agree the allowed endpoints with the platform team before the agent is built. Managed environments add agent-level controls; see DLP policies in Power Platform.

What breaks in practice

OpenAPI files that are technically valid and semantically useless, with operation names like "post_v2_items" and no descriptions. Agents that call an action too eagerly because the description was broad. Flows that time out because the external API is slow and nobody set a sensible timeout. Secrets in variables.

Stability verdict

REST actions, custom connectors, and flow actions are established and stable. MCP support is real and moving fast, which is both its appeal and its risk. For how an agent should be scoped and tested before any of this, read building agents with Copilot Studio.