Inbound (external to UiPath)

How an external agent or client holds a conversation with a conversational agent you deployed in Orchestrator, and how those calls are authenticated.

Remarque :

This functionality is in preview.

Inbound A2A is an external agent or client holding a conversation with a conversational agent you deployed on the UiPath Platform. UiPath is the destination of the call, not a gateway in front of something else.

There is nothing to register for this direction. Every conversational agent deployed to a folder already speaks A2A: Agent Gateway serves its agent card and translates A2A traffic into a native conversation with the agent. Any A2A client can use the agent with just the card URL and a UiPath token.

Because UiPath is the destination, there is only one authentication to configure: the caller authenticating to UiPath. The connections, headers, and Orchestrator asset references that appear in the outbound direction have no counterpart here.

Expose deployed conversational agents

The agent card

Every deployed agent has a card at:

https://cloud.uipath.com/{org}/{tenant}/agenthub_/a2a/{folderKey}/{agentReleaseId}/.well-known/agent-card.json

{folderKey} is the key of the folder the agent is deployed in, and {agentReleaseId} is the release ID of the deployed conversational agent.

The card is generated from the current deployment, so its name, description, and version always match what is deployed. It advertises streaming, text and file input/output, and bearer authentication. There is no anonymous discovery: fetching the card already requires a UiPath token.

You can copy the A2A URL from Automations > Processes > Copy A2A Card URL. You can also inspect both the A2A URL and the agent card from the Deployed Agents tab, after selecting the conversational agent.

Calling the agent

The JSON-RPC (JSON Remote Procedure Call) endpoint is the card URL without the /.well-known/agent-card.json suffix. On the wire, a call looks like this:

POST https://cloud.uipath.com/{org}/{tenant}/agenthub_/a2a/{folderKey}/{agentReleaseId}
Authorization: Bearer <your-access-token>

{
  "jsonrpc": "2.0",
  "id": "1",
  "method": "message/send",
  "params": {
    "message": {
      "messageId": "m1",
      "role": "user",
      "parts": [
        {
          "kind": "text",
          "text": "hi"
        }
      ]
    }
  }
}

One A2A task represents one conversation with the agent. The first message creates the task, and the response carries a contextId; including that ID in the next message continues the same conversation. After each reply, the task state is input-required, keeping the conversation open for follow-up messages.

message/stream returns the reply as an SSE (Server-Sent Events) stream. tasks/get reads a task's state and history, and tasks/cancel cancels a running task. Push notifications and tasks/resubscribe are not supported, so live output requires message/stream.

Authentification

Inbound A2A has a single authentication: the caller authenticating to UiPath. UiPath is the destination of the call, so there is no second hop and no upstream credentials to configure.

Every request carries a bearer token in the Authorization header, the request for the agent card included. There is no anonymous discovery, and nothing is carried forward between turns: each message in a conversation is authenticated on its own.

What the caller needs

The token must be valid for the organization and tenant named in the URL, and the folder named in the URL must be one the calling identity can see. Nothing further is required: no folder permission, no scope specific to A2A, and no equivalent of the View permission on MCP Servers that an outbound call needs. Identity and folder are the whole of what UiPath checks here, and nothing inspects the content of a message.

Any token that works elsewhere on the platform works here: interactive login, external applications, or a Personal Access Token, which is the simplest for testing.

Remarque :

Create a Personal Access Token with the Orchestrator API Access resource selected, because that resource sets the audience this endpoint checks. Without it, the token is rejected before the call reaches the agent, and the error names the audience rather than the token, so it does not look like a scope problem at all.

For how to obtain each token type, check MCP Server authentication.

UiPath validates the token, resolves the folder, and forwards the request to the service that runs the conversational agent, with the caller's token attached. Inbound is the one direction in which the caller's token travels beyond Agent Gateway. It stays inside UiPath, because the service that runs the agent is a UiPath service. On an outbound call the token is stripped at the boundary and replaced with the credentials configured for the remote agent.

Selecting the card version

Only the agent card endpoint reads the optional A2A-Version header; the message endpoint ignores it. A v1.0 client sends the header on its own, so you rarely need to set it yourself.

• Send 1.0 for the strict v1.0 card.
• Send 0.3 for the strict v0.3 card, which carries no v1.0 fields and suits a client whose deserializer rejects unknown properties.
• Send nothing, or any other value, and you get a v0.3 card with the v1.0 supportedInterfaces property added, so that a v1.0 client that did not send the header can still read it.

The message endpoint accepts both wire formats regardless of the header, so a v1.0 and a v0.3 client can talk to the same agent. The value is matched exactly, so 1.0.0 is not treated as 1.0. And omitting the header does not give you the strict v0.3 card here, as it does for a registered remote agent. If you are comparing the two directions, that is why their cards differ.

Résolution des problèmes

For the errors you are most likely to meet and how to resolve them, check Test and troubleshoot A2A. Its Inbound section covers the failures on this path.

For the opposite direction, where UiPath calls an agent hosted elsewhere, check Outbound (UiPath to external).