# 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.

:::note
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:

```plaintext
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:

```plaintext
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`.

## Authentication

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.

![The single authenticated hop of an inbound A2A call: an external client to the conversational agent deployed on the platform](https://dev-assets.cms.uipath.com/assets/images/orchestrator/a2a-inbound-authentication-flow-b016cd5e.webp)

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.

:::note
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](./mcp-server-authentication.md).

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.

## Troubleshooting

For the errors you are most likely to meet and how to resolve them, check [Test and troubleshoot A2A](./test-and-troubleshoot-a2a.md). 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)](./outbound-a2a.md).
