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

The booking_question* and booking_eligibility* codes belong to the booking questions extension and are emitted only when it is negotiated. path on every message is a bracket-form RFC 9535 JSONPath, for example $.booking_question_submissions[?@.set_id=='intake'].answers['allergies'].

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

| payment_failed | Payment processing failed | -32001 |

Observability Join (Non-Normative Recommendation)¶

USP does not require any metric system, log product, or alert route. For implementers who choose to join money-path logs across vendors, the specification recommends a single opaque correlation id per booking flow. Not implementing this recommendation is conformant USP.

• Join key: one opaque, non-PII token per booking flow (a UUID is sufficient).
• Clients (if participating): SHOULD send on money-path operations: registry search, booking, and checkout complete.
• Recipients (if participating): SHOULD propagate on outbound calls (including across bindings), generate when absent, SHOULD NOT overwrite inbound, and SHOULD echo on errors via the binding's carriage mechanism.
• All recipients: SHOULD NOT fail a conformant request because the join id is absent or unrecognized.
• traceparent: MAY be sent on HTTP hops in addition; it is not a second USP join key.

See specification.md Section 9.7 for the full recommendation.

Binding Pages¶