Transport Bindings¶

USP is transport-agnostic. The protocol defines operations and schemas independent of the wire format, allowing businesses and platforms to communicate over whichever transport best fits their architecture.

This section specifies how USP operations map to each supported transport. A business may support one or more bindings simultaneously; a platform selects a binding based on the business profile advertised at /.well-known/usp.

Supported Bindings¶

USP defines four transport bindings:

Choosing a Binding¶

Error Handling Across Transports¶

USP distinguishes between two categories of errors, regardless of transport:

Business outcome errors (e.g., slot unavailable, hold expired, capacity exceeded) are returned as part of a successful response with a messages[] array. In REST this means HTTP 200; in MCP it means a JSON-RPC result (not error); in A2A it means the task completes with data.messages[].

Protocol errors (e.g., malformed requests, authentication failures) use transport-native error mechanisms: HTTP status codes for REST, JSON-RPC error objects for MCP.

Message Fields¶

Each message in the messages[] array carries:

Severity Levels¶

Error Code Mapping¶

Business Outcome Errors¶

These errors are returned via messages[] in the response body (HTTP 200 in REST, result in MCP, data in A2A):

Protocol Errors¶

Protocol errors use transport-native error mechanisms. The mapping across transports:

Transport Flow Comparison¶

graph LR
    subgraph REST
        R1[HTTP Request] --> R2[JSON Body]
        R2 --> R3[HTTP Response]
    end

    subgraph MCP
        M1[JSON-RPC Request] --> M2[tools/call]
        M2 --> M3[structuredContent + content]
    end

    subgraph A2A
        A1[Task Send] --> A2[DataPart]
        A2 --> A3[Task Result]
    end

    subgraph ESP
        E1[esp.ready] --> E2[esp.start]
        E2 --> E3[Delegation Messages]
        E3 --> E4[esp.complete]
    end

Binding Pages¶