UCP for Lodging
UCP has a draft spec for booking hotel stays. dev.ucp.lodging.booking was merged on 24 September 2026. It isn't in a release yet, and its names may still change.
It covers the last step: turning a rate an agent has found into a confirmed reservation, with the hotel's own price, guest details and payment. Finding the room, and changing a booking afterwards, come later.
It was written by the Lodging Technical Council: Amadeus, Booking.com, Expedia, Google, Hilton, Marriott and Trip.com.
-
24 Jun 2026Charter proposed
-
11 Aug 2026Council seated
-
28 Aug 2026Booking capability filed
-
24 Sep 2026Merged as a draft
-
Dec 2026 – Jan 2027Next UCP release (target; lodging not confirmed)
01How a booking works
A booking is a session that moves through six statuses. The platform makes the calls; the business sets the status and says what it needs next. Press play, or step through.
One session, step by step
{
"status": "incomplete",
"stays": [{ "accommodation_type": { "id": "…" },
"rate_plan": { "id": "…" } }],
"totals": [{ "type": "total", "amount": 77600 }],
"expires_at": "2026-09-25T18:30:00Z"
}
The platform opens a session. It sends the stay it found in search. The business answers with its own price and availability, and from here on the session is authoritative. expires_at says how long that price and any inventory hold last.
02What a booking is made of
Select a part to see whether the spec requires it, who sets it, and what it means.
One in-flight booking: the stays, the people, the price and the payment, with a status that says what's needed next.
Required at the top level: id, status, property, stays, currency, totals and links.
The hotel or rental: a location summary plus images and other media. The first media item is the featured one.
Reuses the shared location summary, so a property looks like a store location elsewhere in UCP.
One entry per unit booked. Each binds an accommodation type, a rate plan, stay dates and occupancy: four things that must agree.
Required per stay: id, stay_dates, accommodation_type, rate_plan, totals. The ids come from upstream search and are opaque.
What is being booked: a room type, a villa, a pitch. It has a title, description, capacity and media.
An explicit "type" field (hotel room or vacation rental) is still being decided in #858.
The commercial terms for that unit: flexible, non-refundable, member rate and so on.
Lodging often models "pay now" and "pay later" as separate rate plans; several payment terms per plan are also allowed.
Check-in to check-out, as a date interval.
date_interval is a new shared type, added for lodging.
Adults, children and their ages, and a total. The business checks it against the unit's capacity.
Capacity uses whole-number counts plus child age ranges, so "child" means what the property says it means.
Which guests stay in this unit, each as primary or accompanying.
Unknown roles must be treated as accompanying, so new roles can be added safely.
The person or company that books and pays: name, contact details, company, address.
Kept separate from the guests so corporate, proxy and multi-room bookings work. A booker may also be a guest.
The people who will stay. Each has an id minted by the platform for this session only.
Guest ids must not carry personal data or cross-merchant tracking. Identity beyond the id should wait until the booking is ready to complete.
What the stay costs, all-in: subtotal, fees, taxes, discounts, and one total they add up to.
Price only. When it's paid lives in payment terms.
Payment terms and, when a card is charged or held, the instrument. Required when completing; an empty object is enough for pay-at-property.
The term is chosen during update, because it can change the price.
Rules like cancellation: refundable, partially refundable or non-refundable, with a description that must not contradict it.
Cutoffs and penalties are still in the description text.
How long the session, its quoted price and any inventory hold stay valid.
The business must not complete at a changed price without first returning new totals.
The reservation number once completed, with a label, optional PIN and link.
Must not appear while the status is complete_in_progress.
03Where the money goes, and when
The same total, drawn twice: what the stay costs (totals) and when it's paid (payment terms). The two bars are the same length because the spec says they must add up. Both examples are the spec's own.
3 nights in Tokyo, taxes and fees paid at the hotel
3 nights, first night now and the rest at check-in
total = ¥77,600
sum of schedules in term = ¥77,600
✓ both add up, as the spec requires
The fees paid at the hotel are still in the total: the price is all-in, only the timing differs. The spec also requires a disclosure warning pointing at the at-property schedule, so the guest isn't surprised at check-in.
total = $1,350.00
sum of schedules in term = $1,350.00
✓ both add up, as the spec requires
Early drafts put "due now" inside totals, and review showed the numbers then added up to twice the price. The fix: one total for the price, schedules for the timing. The schedule type is an open list; only immediate has a fixed meaning.
04What the draft covers
Specified, partly specified, or left for later.
| Area | Status | What it says |
|---|---|---|
| Price and availability check | specified | Opening a session switches from search results to the business's own price and availability. It can't complete at a changed price without first returning new totals. |
| All-in price | specified | The total is the whole stay, taxes and fees included, and the guest must see it before confirming. |
| Pay now or at the property | specified | Deposits, balances and property-collected charges are payment schedules that add up to the total. |
| Holding a quoted price | partly | expires_at holds price and inventory inside a session. How long a rate from search stays valid is out of scope. |
| Cancellation terms | partly | Refundable, partly or not, as structured data. Cutoffs and penalties are still text; an open proposal (#861) would structure them. |
| Changes after booking | not yet | Modifications, cancellations and check-in are left to future post-purchase order extensions. |
| Finding the room | not yet | Search and discovery come in a later phase of the charter. |
05What to do now
The draft may change, but three of its rules are safe to build against today.
Make deposits add up
Model deposits and balances as payment-terms schedules against one total, not as extra totals. It's the rule in the draft that is easiest to get right now.
Hold your quoted price
Return updated totals before completing at any price other than the one quoted, and set expires_at to the time your hold really lasts.
Test how agents handle expiry
Our data shows agents book expired offers and miss price changes; run a frontier model through your flow.
06What we'll measure
07Lodging Technical Council (seated 11 Aug 2026)
08Terms
The words this page uses, as the spec uses them.
- Booking session
- An in-flight booking with a status, from the first request until it is completed or canceled.
- Stay
- One booked unit: an accommodation type, rate plan, dates and occupancy together.
- Rate plan
- The commercial terms for a unit, such as flexible or non-refundable.
- Booker
- The person or company that makes and pays for the booking.
- Guest
- A person who will stay, identified by a session-only id.
- Payment schedule
- When part of the total is paid: now, later, or at the property.
09FAQ
Is there a UCP for Lodging spec yet?
A draft one. On 24 September 2026 the Lodging Technical Council's PR #780 was merged, putting dev.ucp.lodging.booking and a cancellation-policy extension into the UCP spec repository, with schemas and REST and MCP bindings. It is marked draft and may change, and it is not in a release yet: v2026-08-25 still ships only dev.ucp.shopping.* and dev.ucp.common.*. Shopping Tech Council minutes target the next release for early December 2026 or January 2027, without saying whether lodging will be in it.
Who sits on the Lodging Technical Council?
The inaugural members announced on 11 August 2026 are Amadeus, Booking.com, Expedia, Google, Hilton, Marriott and Trip.com. The council developed the booking capability, and its 25 September announcement also credits open-source contributors.
What does the draft cover?
The booking core. A platform opens a booking session from a property, stay, rate plan and dates found upstream, adds guest and payment details over one or more updates, and completes it to create a confirmed reservation. The business stays merchant of record, and unless the AP2 mandates extension is used, the user finalises the booking in a trusted UI.
What namespace does UCP for Lodging use?
dev.ucp.lodging. The draft defines dev.ucp.lodging.booking and dev.ucp.lodging.policy.cancellation, with operations named create, get, update, complete and cancel_booking_session. Two things may still change: issue #858 is weighing an explicit accommodation type, and whether to keep the _session suffix or match shopping's shorter verb-noun names. Our checker validates any declared namespace against the spec's authority-binding rule regardless of who defines it.
What changed between the filed PR and the merged draft?
Hotel-only room vocabulary became generic stays (property, stays, accommodation_type, stay_dates). Totals were reworked so they describe what a stay costs, with payment-terms schedules for when it is paid, which must add up to the total. Guest roles became primary and accompanying, guest identifiers stayed platform-minted and free of personal data, and expires_at now covers quoted pricing and temporary inventory holds.
What is still out of scope?
Discovery and search, how long a rate seen in search stays valid before a session exists, and managing a reservation after booking (modifications, cancellations and check-in), which the PR leaves to future post-purchase order extensions. Structured cancellation schedules are a separate open proposal (#861, re-filed from #808).
What should hotels and booking engines do now?
Prototype against a pinned commit of the draft and expect naming changes. Model deposits and balances as schedules that add up to one total, hold your quoted price for as long as expires_at says, and test how AI agents handle an offer that expires mid-session.
10Keep reading
Related reading
UCP Lodging Is Merged: What Changed on the Way to the SpecThe State of Agentic Commerce — September 2026A Room Is Not a SKU — UCP's First Lodging Capability Is in ReviewUCP for Lodging Just Got a Technical CouncilUCP for Lodging Just Got a Charter — and a Phased RoadmapGoogle Opened UCP for Lodging — What It Needs to HandleAgentic AI in Travel: Why UCP Isn't Travel-Ready YetSources
UCP announcement — Lodging Booking capability draft spec release (25 Sep 2026)UCP draft spec — Lodging Booking capabilityUCP PR #780 — Lodging Booking capability and cancellation policy extension (merged)UCP issue #858 — design TODOs deferred from #780UCP issue #543 — [DTC Charter]: LodgingGoogle for Developers — UCP for LodgingUCP release v2026-08-25 — multi-vertical refactoringOther UCP verticals
UCP for Retail
LiveThe first and largest UCP vertical — agents search catalogs, build carts, and check out across thousands of verified stores.
18,994 verified merchantsUCP for Travel
AnnouncedFlights, rail and travel distribution are agentic commerce's hardest vertical — perishable inventory and dynamically generated offers, not fixed SKUs.
UCP for Food Ordering
Technical Council formed · spec in progressUCP has a seated Food Technical Council and a phased roadmap that starts at checkout, not the menu — but no food namespace and no published schema. Here's what it still has to handle.
UCP for B2B
Community-debated · no official UCP B2B spec yetB2B isn't an officially-named UCP vertical, but it's the most-debated one. Where UCP actually fits B2B today — and the primitives the spec would have to add for the rest.
UCP for Services
Community-proposed · no official UCP services spec yetAppointments, classes, reservations and rentals sell time, not stock. UCP has no services namespace yet — but a Governing Council working group is being explored, and scheduling capabilities are already turning up in real UCP profiles.
Explore protocol data
Is your booking engine agent-ready?
Whichever vertical you're in, the prerequisite is the same: a valid, machine-readable UCP endpoint an agent can actually transact against.
Get the agentic commerce digest every Monday
Real adoption data, ecosystem trends, new spec versions, and the stores that broke or recovered this week. Read by founders and engineers building the next generation of commerce.