Calling Genie from Copilot Studio: what the Conversation API needs from you

Early in 2026 someone asked on the Databricks Community forum whether a Microsoft Copilot Studio agent can connect to a Genie space on AWS. The question was short. The answer, which a Databricks employee posted in March, was yes: through the Genie Conversation API, using either the HTTP request node in Copilot Studio or a Power Automate cloud flow.

“Yes, it is possible” is the easy half. The harder half is everything the API does not do for you. If you wire it up as a single request and a single response, it will work in a demo and fail the first time a question takes a while to answer. This post covers what we would build around it.

(Genie Spaces are now called Genie Agents. Older threads and some API paths still say “space”.)

The API is asynchronous, so you poll

You start a conversation, and the answer is not in the response. The response gives you a message that you check until it reaches a conclusive state. The Databricks documentation for the Conversation API names COMPLETED, FAILED and CANCELLED as conclusive statuses and gives this polling guidance:

• Poll every 1 to 5 seconds.
• Back off as you go, up to a maximum delay of one minute.
• Stop after about 10 minutes for most queries, then return a timeout or ask the user to check back.

Treat those as the starting point for your own loop. In Copilot Studio that loop is condition nodes. In Power Automate it is a Do Until action. Either way, you need an exit condition for each of the three conclusive statuses, not just the happy one.

The default timeout is the first thing that bites

The forum answer pointed out that the simple HTTP request approach is limited by a default timeout of 30 seconds, which long Genie queries can exceed. That comes from the reply, not from Databricks documentation, so check the current limit in your tenant. But the shape of the problem is real: a question that makes Genie generate SQL and wait for a warehouse can take longer than a chat channel feels comfortable with.

Our view: if the use case is more than a quick lookup, put the polling in a Power Automate flow, which the same reply described as more robust and able to run for several minutes. Keep the Copilot Studio side thin. It sends the question, hands the user a “working on it” message, and returns the answer when the flow finishes.

Use a service principal, not a personal token

The forum reply suggested a personal access token for a proof of concept and OAuth with a service principal for production. We agree with that split, and the docs back the direction: they recommend OAuth for users (U2M) when a person with a browser is present, and OAuth for service principals (M2M) when browser sign-in isn’t possible. A Copilot Studio agent calling out from Microsoft’s cloud is the second case.

The catch with a service principal is that it becomes the identity every question runs as. The documentation requires that it has access to the data and the SQL warehouses it needs. Concretely, for prompts through the API it needs CAN VIEW on the Genie Agent and SELECT on the Unity Catalog objects the agent uses. That has a governance consequence you should decide on deliberately:

• If one service principal serves everyone in Copilot Studio, every user sees whatever that principal can see. Row filters and column masks keyed to the end user will not apply to them.
• If you need per-user permissions, you need a flow that authenticates as the user (U2M), which is harder to build inside a Microsoft low-code tool.

Make that choice before the demo, not after someone asks why a sales rep can see finance data.

Network reach

Copilot Studio runs in Microsoft’s cloud. The forum reply noted that your Databricks workspace must be reachable from it, and that IP access lists or private networking may need changes. If your workspace is locked down, find that out in week one. It is the kind of issue that sits in a security review for a month.

The API does not retry for you

The docs say plainly that the API doesn’t retry failed requests. So your integration owns:

• retries with exponential backoff for transient failures,
• a clear message when the status is FAILED,
• queuing if many users ask at once.

The documentation page we read doesn’t state rate limits or concurrency limits, so we can’t give you a number. Don’t invent one. Load-test with realistic traffic against your own warehouse, and watch for throttling responses.

One older forum thread is a useful reminder of what a failure looks like. A developer got a message ID back and then a failed status on the follow-up read. The only reply pointed at the query and data side, not the API call: check that the table exists, that the agent can access the catalog and schema, and that the token has the right permissions. In other words, a FAILED message is usually a data-access or generation problem, so surface the error text to whoever runs the agent rather than a generic “something went wrong”.

Conversation hygiene

Two documented practices are easy to skip:

• Start a new conversation for each session. The docs warn that reusing threads across sessions can reduce accuracy through unintended context reuse. A chat bot that keeps one conversation per user forever is doing exactly that.
• Prune old conversations. An agent supports 200,000 conversations, and the docs suggest listing and deleting old or test ones. A busy chat channel can fill that up with test and abandoned conversations.

Also log requests and responses on your side. The docs recommend it for debugging and usage tracking, and the Monitoring tab and audit logs cover the Databricks side.

The agent still decides the quality

The forum reply ended with the point we would put first: answer quality depends on how well the Genie Agent is curated. The documented limit is 50 tables, views or metric views per agent, with five or fewer recommended. A Copilot Studio front end does not make a vague agent accurate. It just puts a vague agent in front of more people. Build and benchmark the agent first, then expose it.

Summary

• Copilot Studio can call Genie through the Conversation API, with an HTTP request node or a Power Automate flow.
• The API is asynchronous. Poll until COMPLETED, FAILED or CANCELLED, with backoff and a roughly 10-minute ceiling.
• Prefer Power Automate for anything beyond quick lookups, because of the HTTP node’s reported 30-second default timeout.
• Use OAuth with a service principal in production, and decide deliberately whether everyone sharing one identity is acceptable.
• Check network reach from Microsoft’s cloud to your workspace early.
• You own retries and queuing; the docs publish no rate limits, so test your own load.
• Start a new conversation per session, prune old ones, and benchmark the agent before you put a chat front end on it.

If you are planning to put Genie behind another tool and want a second pair of eyes on the auth, governance and rollout side, Zephico offers a Genie readiness review, a pilot sprint, and rollout and governance support. We are a Databricks Consulting Partner. Details are on our Databricks Genie page.