Quote Lookup via Custom Connector

---

The problem

An insurance brokerage runs its policies and quotes in a line of business system that predates its Microsoft estate. Staff answering client calls hold two windows open: Teams, and the broker platform. Every status question means alt-tabbing, searching a reference number, and reading a record aloud.

The vendor sells a portal. The portal is another login, another interface to learn, and it still does not put the answer where the conversation is happening.

Why a connector rather than an integration project

The system already has a REST API. The gap is not capability, it is surface: no path exists between the API and the tools staff work in. A custom connector closes that gap without a middleware layer. Once defined, the same connector serves Copilot Studio, Power Automate, and Power Apps.

Where this is the wrong answer: if the API is chatty enough to need orchestration across several calls per question, or the data needs reshaping before it is usable, the logic belongs in a flow or an Azure Function behind the connector rather than in the agent.

Architecture

The connector is defined from the vendor's OpenAPI specification, which maps each endpoint to a named action with typed inputs and outputs. The agent calls one action, passes the client reference, and receives structured fields it can speak back conversationally.

The constraint that drives the design

Authentication is where most of the work goes.

The API authenticates with OAuth 2.0. The connector holds the client credentials and the token exchange, so nothing sensitive lives in the agent or in a topic variable. Token refresh happens in the connector layer, invisibly to the conversation.

This is also where the security conversation lands. A connector that authenticates as a single service account gives every user the access of that account. Where the underlying system has per user permissions, the connector must pass the user's identity through rather than flatten it. Otherwise, the agent quietly becomes a privilege escalation path.

Delivery considerations

The OpenAPI spec is the contract. A clean spec produces a clean connector. A vague one has to be corrected by hand in the connector definition, and that correction is where most of the effort goes.

Error responses need mapping. A 404 from the API should become "I can't find that reference," not a raw fault surfaced into the chat.

Rate limits belong in the design. Agents can generate more calls than a human ever would, and vendor throttling is discovered in production unless it is checked first.

Vendor API changes break connectors silently. Version pinning and an owner for the connector definition are part of handover, not an afterthought.