Announcing UCP Lodging: Booking Capability Draft Spec Release!

[amithanda]

Hello UCP Community! 👋

We are excited to announce that the initial draft version of the Lodging Booking capability has been merged into the Universal Commerce Protocol repository!
Following our multi-vertical architecture milestone, this release marks the formal expansion of UCP into the Lodging domain. Developed by Lodging Tech Council composed of lodging industry leaders, this standardized open-source capability empowers developers and platforms to build seamless, end-to-end agentic travel booking experiences. It’s now open for public feedback and contributions.

✨ Capability Highlights

The new dev.ucp.lodging.booking capability unlocks the foundational booking flow for hotel reservations:

• Real-Time Checks: Enable high-quality booking flows within AI surfaces with real time pricing and availability checks for rooms to ensure accuracy.
• Easy guest registration: Captures comprehensive guest details, occupancy counts, stay duration (check-in/check-out dates), and custom accommodation requirements.
• Secure checkout with Complex Payment Schedules: Supports advanced lodging payment lifecycles, including deposit structures, deferred balances, split payments, and cancellation/refund policies tied to the booking lifecycle.
• Cross-Vertical Primitive Interoperability: Seamlessly integrates with core UCP primitives like Identity linking and payment handlers.

🔗 Quick Links & Documentation

• 📖 UCP Lodging Documentation: https://ucp.dev/draft/specification/lodging/booking/

🙏 Acknowledgments

A special thank you to the Lodging Tech Council including Amadeus, Booking.com, Expedia, Google, Hilton, Marriott, Trip.com and open source contributors for shaping these draft specifications so far, and looking forward to working with the open source community to build upon this.

💬 Feedback & Discussion

We welcome public feedback, questions, and feature suggestions from the ecosystem. Please drop your thoughts in the discussion below!

[KukretiShubham]

Great news! We’ve been following UCP’s development, and our customers’ agents have been using it. Thanks for opening this proposal for feedback.

We’ve been implementing an agent-assisted flight + hotel booking flow. Some of the hardest problems have been uncertain outcomes and keeping the reviewed itinerary aligned with the eventual booking. It’s encouraging to see the accepted-completion and authentication-action contracts already address several of these concerns.

A few questions from that implementation experience- some may already be covered by inherited contracts, so pointers or worked examples would be helpful:

1. What happens when completion outlives the session?

If Complete is accepted before expires_at, but the supplier/payment result arrives afterward, how should the agent recover the authoritative outcome?

The inherited accepted-completion contract stops repeated Get requests at expiry. Is there a durable outcome lookup and minimum retention period after that point? What evidence establishes that it is safe to offer a replacement booking without risking a duplicate?

References: Session expiry and inventory management, Accepted completion.

2. How do API completion and human handoff avoid creating two reservations?

Could you provide a conformance example where an API completion times out while the buyer completes the same session through continue_url?

Those operations might not share an idempotency key. What session-level guarantee ensures one logical reservation across both surfaces, including when the original request is still processing?

References: Continue URL, REST idempotency requirements.

3. What invalidates approval when the price stays unchanged?

If a refundable room becomes non-refundable, or payment changes from pay-later to immediate, without changing the total, how is earlier buyer approval invalidated?

AP2 already binds the approved response. Could a lodging-specific example show how stale approval is rejected and fresh approval obtained—both with AP2 and in ordinary trusted-UI completion?

Reference: AP2 business verification.

4. Can required guest information be supplied before “ready”?

The guidelines recommend withholding guest identity until ready_for_complete, while also requiring an identified lead before the business returns that status.

When the primary guest supplies the lead identity and there is no separate booker, should the platform send the requested minimum name/contact while the session is still incomplete? Could that exception and sequence be explicit, while preserving the intent to minimize personal-data collection?

Reference: Platform and business guidelines.

5. Where should an agent discover all room/rate alternatives?

We understand that Booking consumes identifiers from upstream discovery rather than defining the entire search flow.

Is there a planned or recommended discovery capability for enumerating available room/rate combinations and their selection dependencies? An end-to-end example would help distinguish the selected booking snapshot from the complete set of alternatives, without losing differences such as refundability, meal inclusion, or payment timing.

Reference: Provisional discovery vs. authoritative booking.

We’d be happy to contribute anonymized examples or conformance-test scenarios from our integration, particularly around late results, concurrent API/UI completion, and conditional guest or billing requirements.