Requests
Syntax
The Transaction (Property Data)
message uses the following syntax:
<?xml
version="1.0"
encoding="UTF-8"?>
<Transaction
timestamp=" timestamp
"
id=" message_ID
"
partner=" partner_key
">
<PropertyDataSet
action="[overlay|delta]">
<!--
(Required)
ID
that
matches
the
Hotel
List
Feed
-->
<Property> HotelID
</Property>
<RoomData>
<!--
(Required)
One
room
ID
per
RoomData
element
-->
<RoomID> RoomID
</RoomID>
<Name>
<Text
text=" room_name
"
language=" language_code
"/>
</Name>
<Description>
<Text
text=" room_description
"
language=" language_code
"/>
</Description>
<!--
(Optional)
Restricts
the
rate
plans
allowed
for
this
room
type
to
those
listed
here.
If
specified,
don't
specify
AllowableRoomIDs.
-->
<AllowablePackageIDs>
<AllowablePackageID> PackageID
</AllowablePackageID>
</AllowablePackageIDs>
<Capacity> max_number_of_occupants
</Capacity>
<AdultCapacity> max_number_of_adult_occupants
</AdultCapacity>
<ChildCapacity> max_number_of_child_occupants
</ChildCapacity>
<OccupancySettings>
<MinOccupancy> min_number_of_occupants
</MinOccupancy>
<MinAge> min_age_of_occupants
</MinAge>
</OccupancySettings>
<PhotoURL>
<Caption>
<Text
text=" photo_description
"
language=" language_code
"/>
</Caption>
<URL> photo_location
</URL>
</PhotoURL>
<RoomFeatures>
<JapaneseHotelRoomStyle>[western|japanese|japanese_western]</JapaneseHotelRoomStyle>
<Beds>
<Bed
size="[single|semi_double|double|queen|king]">
<Width
unit="cm"
number=" bed_width
"/>
<Length
unit="cm"
number=" bed_length
"/>
</Bed>
<!--
Include
with
any
additional
beds.
-->
</Beds>
<Suite/>
<Capsule/>
<Roomsharing>[shared|private]</Roomsharing>
<Outdoor/>
<MobilityAccessible/>
<Smoking>[smoking|non_smoking]</Smoking>
<BathAndToilet
relation="[together|separate]">
<Bath
bathtub="[false|true]"
shower="[false|true]"/>
<Toilet
electronic_bidet="[false|true]"
mobility_accessible="[false|true]"/>
</BathAndToilet>
<OpenAirBath/>
<AirConditioning/>
<Balcony/>
<Views>
<!--
(Optional)
Defines
the
type
of
views
from
the
room.
-->
<!--
Example:
<OceanView/>
-->
</Views>
</RoomFeatures>
</RoomData>
<PackageData>
<!--
(Required)
One
package
ID
per
PackageData
element
-->
<PackageID> PackageID
</PackageID>
<Name>
<Text
text=" package_name
"
language=" language_code
"/>
</Name>
<Description>
<Text
text=" package_description
"
language=" language_code
"/>
</Description>
<!--
(Optional)
Restricts
the
room
types
allowed
for
this
rate
plan
to
those
listed
here.
If
specified,
don't
specify
AllowablePackageIDs.
-->
<AllowableRoomIDs>
<AllowableRoomID> RoomID
</AllowableRoomID>
</AllowableRoomIDs>
<!--
Add
Loyalty
point
information
-->
<MilesIncluded>
<LoyaltyCampaignID> campaign-ID
</LoyaltyCampaignID>
<!--
(Optional)
Use
<NumberOfMiles>
if
the
rate
plan
earns
fixed
loyalty
rewards-->
<NumberOfMiles> integer
</NumberOfMiles>
</MilesIncluded>
<Refundable
available="[false|true]"
refundable_until_days=" number_of_days
"
refundable_until_time=" time
"/>
<!--
For
these
next
3
elements,
boolean_value
can
be
0/1
or
true/false
-->
<BreakfastIncluded> boolean_value
</BreakfastIncluded>
<InternetIncluded> boolean_value
</InternetIncluded>
<ParkingIncluded> boolean_value
</ParkingIncluded>
<PhotoURL>
<Caption>
<Text
text=" photo_description
"
language=" language_code
"/>
...
</Caption>
<URL> photo_location
</URL>
</PhotoURL>
...
<Meals>
<Breakfast
included="[true|false]"
buffet="[true|false]"
in_room="[true|false]"
in_private_space="[true|false]"/>
<Dinner
included="[true|false]"
buffet="[true|false]"
in_room="[true|false]"
in_private_space="[true|false]"/>
</Meals>
<CheckinTime> checkin_time
</CheckinTime>
<CheckoutTime> checkout_time
</CheckoutTime>
</PackageData>
</PropertyDataSet>
</Transaction>
Elements and Attributes
The Transaction (Property Data) message has the following elements and attributes:
Note:
If you have a backend that provides feeds for
multiple accounts, this value needs to match the ID
attribute value specified in the <RequestorID>
element of your <OTA_HotelRateAmountNotifRQ>
and <OTA_HotelAvailNotifRQ>
messages for the same account.
The type of update to apply to room rate definitions.
Valid values are:
-
overlay :
Replaces all previously defined<RoomData>
and<PackageData>
for the property. Only the<RoomData>
and<PackageData>
in the current message are valid. -
delta :
Adds previously undefined<RoomData>
and<PackageData>
or modifies existing ones.
This attribute is optional and defaults to delta
if not
specified.
<id>
in the <listing>
element
in the Hotel List Feed. The Hotel ID is also listed in Hotel Center
.Describes a room.
Note:At least one of <RoomData>
or <PackageData>
is required.
InvTypeCode
attribute in the <StatusApplicationControl>
element in <OTA_HotelAvailNotifRQ>
, <OTA_HotelRateAmountNotifRQ>
and <OTA_HotelInvCountNotifRQ>
messages.language
attribute.language
attribute.<AllowablePackageID>
elements. If <AllowablePackageIDs>
is specified, the room
type identified by the <RoomID>
in the parent <RoomData>
element can only be
combined with the rate plans defined by the <AllowablePackageID>
elements.
If <AllowablePackageIDs>
isn't specified, the room
type identified by the <RoomID>
in the parent <RoomData>
element can be combined with any
rate plan.
Use either <AllowablePackageIDs>
or <AllowableRoomIDs>
, but not both.
PackageID
corresponds to the RatePlanCode
in the
OTA_HotelRateAmountNotifRQ and OTA_HotelAvailNotifRQ messages.NumberOfGuests
values that you send with rates. The value of <Capacity>
must be a positive integer
between 1
and 99
, inclusive. See here
for an example.
Note:
If <Capacity>
is not set, the number
of allowed occupants is considered unlimited. If this field
is not set and ExtraGuestCharges
or AdditionalGuestAmounts
are defined, prices
can be generated for any number of occupants. We recommend
that you set the <Capacity>
if ExtraGuestCharges
or AdditionalGuestAmounts
are defined to ensure that prices
are not displayed for occupancy options that are invalid.
NumberOfGuests
values that you send with rates. The value of <AdultCapacity>
must be a positive
integer between 1
and 99
, inclusive. See here
for an example.
The value of <ChildCapacity>
must be a positive
integer between 1 and 99, inclusive. See here
for an example.
The <OccupancySettings>
element takes the
following child elements:
-
<MinOccupancy>
: The minimum number of guests that can stay in a room. For example, if this is set to2
, this room cannot be booked for a single guest.The value of
<MinOccupancy>
must be a positive integer between 1 and 99, inclusive. -
<MinAge>
: The minimum age for all guests staying in a room. For example, if this is set to18
, this room can only be booked for groups where all guests are of age 18 or above.The value of
<MinAge>
must be a positive integer between 0 and 99, inclusive.
<OccupancySettings> <MinOccupancy>2</MinOccupancy> <MinAge>16</MinAge> </OccupancySettings>
Not all child elements need to be included.
<PhotoURL>
for a room or Room Bundle. This element takes the following child elements:
-
<URL>
: Specifies the location of the photo. The location should be public (not behind a firewall) and should include the protocol (http://
). -
<Caption>
: Defines the caption for the photo. This element takes a single child element,<Text>
, which has two required attributes,Text
andlanguage
. TheText
attribute is the caption, and thelanguage
attribute specifies a two-letter language code such asen
.
<PhotoURL> <URL>http://www.example.com/image1.jpg</URL> <Caption> <Text text="A bright way to enjoy your mornin' cuppa tea." language="en"/> <Text text="Une façon lumineuse pour profiter de votre tasse de thé." language="fr"/> </Caption> </PhotoURL>
Indicates the style of a Japanese hotel room.
Valid values are:
-
western
: A western style room with beds. -
japanese
: A Japanese style room with futon beds. -
japanese_western
: A Japanese western style room with both western style beds and Japanese style futons.
<Bed>
as the room has. Please note
that Japanese futons should not be counted here. Each <Bed>
has the following attributes:
-
size
(optional): Valid values aresingle
,semi_double
,double
,queen
, andking
.
<Bed>
has the following child elements: -
<Width>
(optional): Specifies the bed width. Must have the attributeunit
with the valuecm
and the attributenumber
with the width of the bed in integer centimeters. -
<Length>
(optional): Specifies the bed length. Must have the attributeunit
with the valuecm
and the attributenumber
with the length of the bed in integer centimeters.
<Beds> <Bed size="double"> <Width unit="cm" number="140"/> <Length unit="cm" number="195"/> </Bed> <Bed/> <!-- Size unknown --> </Beds>
shared
and private
.non_smoking
and smoking
.The attribute is:
-
relation
(optional): Indicates how the bath and toilet are placed in relation to each other. Valid values aretogether
, for example, a bathroom where both bath and toilet are located together in the same room; andseparate
, where bath and toilet each have dedicated spaces. This attribute must not be set when the room doesn't have both a bath and toilet.
The element optionally takes the following child elements:
-
<Bath>
(optional): The existence of this element indicates that the room has a bath.The attributes are:
-
bathtub
(optional): Indicates that the bath has a bathtub in the bathroom. Valid values are0
(orfalse
) and1
(ortrue
). -
shower
(optional): Indicates that the bath has a shower. Valid values are0
(orfalse
) and1
(ortrue
).
-
-
<Toilet>
(optional): The existence of this element indicates that this room has a toilet.The attributes are:
-
electronic_bidet
(optional): Indicates that the toilet has an electronic bidet . Valid values are0
(orfalse
) and1
(ortrue
). -
mobility_accessible
(optional): Indicates that the toilet is mobility-accessible. Valid values are0
(orfalse
) and1
(ortrue
).
-
Example:
<BathAndToilet relation="separate"> <Bath bathtub="1" shower="1"/> <Toilet electronic_bidet="1" mobility_accessible="1"/> </BathAndToilet>
<AirportView/>
<BayView/>
<BeachView>/>
<CastleView/>
<CityView/>
<CountrysideView/>
<CourtyardView/>
<DuneView/>
<ForestView/>
<GardenView/>
<GolfCourseView/>
<HarborView/>
<LagoonView/>
<LakeView/>
<MarinaView/>
<MountainView/>
<NatureView/>
<OceanView/>
<ParkView/>
<PartialOceanView/>
<PisteView/>
<PoolView/>
<PyramidView/>
<RiverView/>
<StreetView/>
Container for elements that describe rate features and terms that aren't part of the physical room description.
Note:At least one of <RoomData>
or <PackageData>
is required.
PackageID
in these messages corresponds to the RatePlanCode
in the OTA_HotelRateAmountNotifRQ and
OTA_HotelAvailNotifRQ messages.language
attribute.language
attribute.<AllowableRoomID>
elements. If <AllowableRoomIDs>
is specified, the rate plan
identified by the <PackageID>
in the parent <PackageData>
element can only be
combined with the room types defined by the <AllowableRoomID>
elements.
If <AllowableRoomIDs>
isn't specified, the rate
plan identified by the <PackageID>
in the parent <PackageData>
element can be combined with any
room type.
Use either <AllowablePackageIDs>
or <AllowableRoomIDs>
, but not both.
<RoomData>
element.<MilesIncluded>
element within the <PackageData>
element that defines the rate plan. <MilesIncluded>
has the following child element: -
LoyaltyCampaignID
: A unique ID that identifies the specific Loyalty campaign that was configured and updated with Google. It adds loyalty points to the hotel price.To include
<MilesIncluded>
element campaign ID should be configured in the Loyalty Campaign configuration. The specific details on how Google uses loyalty points in the results are determined by the Loyalty Campaign configuration.<MilesIncluded> <LoyaltyCampaignID>my_campaign</LoyaltyCampaignID> </MilesIncluded>
Note:In rare cases you can include
<NumberOfMiles>
under the<MilesIncluded>
element to specify that the plan always earns a fixed number of points, regardless of the itinerary. Learn more about<MilesIncluded>
in<PackageData>
.
Note: We recommend setting all of the attributes. A feed status warning message is generated when one or more attributes are not set.
If you don't set any attributes, the rate does not display as refundable.
When setting the attributes, note the following:
- If
available
orrefundable_until_days
isn't set, the rate does not display as refundable. - If
available
is0
orfalse
, the other attributes are ignored. The rate does not display as refundable even if one or both of the other attributes is set.
1
or true
to indicate if the rate allows a full
refund; otherwise set to 0
or false
.available
is true
) Specifies
the number of days in advance of check-in that a full refund can be
requested. The value of refundable_until_days
must be an integer between 0 and 330, inclusive.available
is true
) Specifies
the latest time of day, in the local time of the hotel, that a full
refund request will be honored. This can be combined with refundable_until_days
to specify, for
example, that "refunds are available until 4:00PM two days before
check-in". If refundable_until_time
isn't set, the value
defaults to midnight.0
(or false
) and 1
(or true
). It is preferred that you use <Meals>
instead of <BreakfastIncluded>
.
0
(or false
) and 1
(or true
).The <Meals>
element takes two optional child
elements, <Breakfast>
and <Dinner>
,
which have the following attributes:
-
included
(required): Set to1
(ortrue
) if the rate includes breakfast/dinner; otherwise set to0
orfalse
. -
in_room
(optional): Set to1
(ortrue
) if guests have the option to have breakfast/dinner in the room they stay in; otherwise set to0
(orfalse
). -
in_private_space
(optional): Set to1
(ortrue
) if guests have the option to have breakfast/ dinner in a space (except the room they stay in) where they can avoid contact with other guests; otherwise set to0
(orfalse
). -
buffet
(optional): Set to1
(ortrue
) if breakfast/dinner is served as a buffet; otherwise set to0
(orfalse
).
The optional attributes are used only when included
is
true.
For meal filters ( no meals
, breakfast only
, dinner only
and breakfast and dinner
) to work,
both <Breakfast>
and <Dinner>
need
to be provided with the included
attribute.
0
(or false
) and 1
(or true
). The default value is false
.<PhotoURL>
in <RoomData>
,
but for the package (e.g. meal photos).)Examples
Room and package data
The following is a basic example of how to define a property's room and
package data in a Transaction (Property Data) message. The overlay
attribute is used to ensure that, if any data unexpectedly exists already,
all existing data is deleted and replaced with the data in this message:
<?xml
version="1.0"
encoding="UTF-8"?>
<Transaction
timestamp="2020-05-18T16:20:00-04:00"
id="12345678"
partner="partner_key">
<PropertyDataSet
action="overlay">
<Property>Property_1</Property>
<RoomData>
<RoomID>RoomID_1</RoomID>
<Name>
<Text
text="King"
language="en"/>
</Name>
<Description>
<Text
text="Room
with
a
king
bed"
language="en"/>
</Description>
<Capacity>2</Capacity>
<PhotoURL>
<URL>http://www.foo.com/static/bar/image.jpg</URL>
<Caption>
<Text
text="Room
with
a
king
bed"
language="en"/>
</Caption>
</PhotoURL>
</RoomData>
<RoomData>
<RoomID>RoomID_2</RoomID>
<Name>
<Text
text="Double"
language="en"/>
</Name>
<!--
Additional
RoomData
child
elements
omitted.
-->
</RoomData>
<PackageData>
<PackageID>PackageID_1</PackageID>
<Name>
<Text
text="Standard"
language="en"/>
</Name>
<Description>
<Text
text="Standard
rate"
language="en"/>
</Description>
<MilesIncluded>
<LoyaltyCampaignID>my_campaign</LoyaltyCampaignID>
</MilesIncluded>
<Refundable
available="true"
refundable_until_days="7"
refundable_until_time="18:00:00"/>
<BreakfastIncluded>0</BreakfastIncluded>
</PackageData>
<PackageData>
<PackageID>PackageID_2</PackageID>
<Name>
<Text
text="Free
Breakfast"
language="en"/>
</Name>
<Description>
<Text
text="Free
breakfast
rate"
language="en"/>
</Description>
<Refundable
available="true"
refundable_until_days="7"
refundable_until_time="18:00:00"/>
<BreakfastIncluded>1</BreakfastIncluded>
</PackageData>
</PropertyDataSet>
</Transaction>
Add a room type
The following is an example of how to add a room type and package to
existing <Transaction>
data:
<?xml
version="1.0"
encoding="UTF-8"?>
<Transaction
timestamp="2020-07-18T16:20:00-04:00"
id="12345678"
partner="partner_key">
<PropertyDataSet
action="delta">
<Property>Property_1</Property>
<RoomData>
<RoomID>RoomID_3</RoomID>
<Name>
<Text
text="Queen"
language="en"/>
</Name>
<!--
Additional
RoomData
child
elements
omitted.
-->
</RoomData>
<PackageData>
<PackageID>PackageID_3</PackageID>
<Name>
<Text
text="Non-Refundable"
language="en"/>
</Name>
<!--
Additional
PackageData
child
elements
omitted.
-->
<Refundable
available="false"/>
</PackageData>
</PropertyDataSet>
</Transaction>
Remove room types
The following is an example of how to remove existing room types and
packages. In this scenario, if the messages in the "Room and package data"
and "Add a room type" had been sent to Google previously, the King
and Double
room types would no longer exist once Google receives the message
shown. Note that removing package data affects the overall rate plan
as defined across Transaction (Property Data), OTA_HotelRateAmountNotifRQ,
and OTA_HotelAvailNotifRQ
messages (by referencing the same PackageID
value), and thus corresponding updates using the other message types may be
required to reflect that PackageID_2
and PackageID_3
are no longer
defined here.
<?xml
version="1.0"
encoding="UTF-8"?>
<Transaction
timestamp="2020-08-18T16:20:00-04:00"
id="12345678"
partner="partner_key">
<PropertyDataSet
action="overlay">
<Property>Property_1</Property>
<RoomData>
<RoomID>RoomID_1</RoomID>
<Name>
<Text
text="Queen"
language="en"/>
</Name>
<!--
Additional
RoomData
child
elements
omitted.
-->
<Capacity>2</Capacity>
<PhotoURL>
<URL>http://www.foo.com/static/bar/image.jpg</URL>
<Caption>
<Text
text="Room
with
a
queen
bed"
language="en"/>
</Caption>
</PhotoURL>
</RoomData>
<PackageData>
<PackageID>PackageID_1</PackageID>
<Name>
<Text
text="Refundable"
language="en"/>
</Name>
<!--
Additional
PackageData
child
elements
omitted.
-->
<Refundable
available="true"
refundable_until_days="7"
refundable_until_time="18:00:00"/>
<BreakfastIncluded>0</BreakfastIncluded>
</PackageData>
</PropertyDataSet>
</Transaction>
Restrict rate plans
The following is an example of how to use the <AllowablePackageIDs>
element to restrict the rate plans allowed for a room type. In this example,
the Queen
room type ( RoomID_2
) can only be combined with the package and
rate plan identified as PackageID_1.
<?xml
version="1.0"
encoding="UTF-8"?>
<Transaction
timestamp="2020-12-18T16:20:00-04:00"
id="12345678"
partner="partner_key">
<PropertyDataSet
action="overlay">
<Property>Property_1</Property>
<RoomData>
<RoomID>RoomID_1</RoomID>
<Name>
<Text
text="King"
language="en"/>
</Name>
<!--
Additional
RoomData
child
elements
omitted.
-->
</RoomData>
<RoomData>
<RoomID>RoomID_2</RoomID>
<Name>
<Text
text="Queen"
language="en"/>
</Name>
<AllowablePackageIDs>
<AllowablePackageID>PackageID_1</AllowablePackageID>
</AllowablePackageIDs>
<!--
Additional
RoomData
child
elements
omitted.
-->
</RoomData>
<PackageData>
<PackageID>PackageID_1</PackageID>
<Name>
<Text
text="Standard"
language="en"/>
</Name>
<!--
Additional
PackageData
child
elements
omitted.
-->
<Refundable
available="true"
refundable_until_days="7"
refundable_until_time="18:00:00"/>
<BreakfastIncluded>0</BreakfastIncluded>
</PackageData>
<PackageData>
<PackageID>PackageID_2</PackageID>
<Name>
<Text
text="Free
Breakfast"
language="en"/>
</Name>
<!--
Additional
PackageData
child
elements
omitted.
-->
<Refundable
available="true"
refundable_until_days="7"
refundable_until_time="18:00:00"/>
<BreakfastIncluded>1</BreakfastIncluded>
</PackageData>
</PropertyDataSet>
</Transaction>
Restrict room capacity
The following is an example of how to use the <Capacity>
, <AdultCapacity>
, <ChildCapacity>
elements to set restrictions on room capacities.
<?xml
version="1.0"
encoding="UTF-8"?>
<Transaction
timestamp="2020-12-18T16:20:00-04:00"
id="12345678"
partner="partner_key">
<PropertyDataSet
action="overlay">
<Property>Property_1</Property>
<RoomData>
<RoomID>RoomID_1</RoomID>
<Name>
<Text
text="Double"
language="en"/>
</Name>
<Capacity>4</Capacity>
<AdultCapacity>4</AdultCapacity>
<ChildCapacity>3</ChildCapacity>
<!--
Additional
RoomData
child
elements
omitted.
-->
</RoomData>
</PropertyDataSet>
</Transaction>
The Double room type (RoomID_1) may have up to 4 guests total. Additionally, it may have up to 4 adults and up to 3 children. All three capacity requirements must be satisfied in order for this room to be bookable. This configuration is representative of a typical room with two beds that each fit two people. The child capacity is one less than the total capacity because the room must have at least one adult present.
Extended examples with <RoomFeatures>
and meals
JapaneseHotelRoomStyle
doesn't have a default value.
Omitting a value does not result in an XML error, but your listing is not
shown in the search results, when the user filters by room style or beds.
Two single beds
The following example shows how to use <RoomFeatures>
:
<?xml
version="1.0"
encoding="UTF-8"?>
<Transaction
timestamp="2017-07-18T16:20:00-04:00"
id="42">
<PropertyDataSet>
<Property>1234</Property>
<RoomData>
<RoomID>RoomID_1</RoomID>
<RoomFeatures>
<JapaneseHotelRoomStyle>western</JapaneseHotelRoomStyle>
<Beds>
<!--
Two
single
beds
-->
<Bed
size="single">
<Width
unit="cm"
number="97"/>
<Length
unit="cm"
number="195"/>
</Bed>
<Bed
size="single">
<Width
unit="cm"
number="97"/>
<Length
unit="cm"
number="195"/>
</Bed>
</Beds>
<Suite/>
<Capsule/>
<Roomsharing>private</Roomsharing>
<Outdoor/>
<MobilityAccessible/>
<Smoking>non_smoking</Smoking>
<BathAndToilet
relation="separate">
<Bath
bathtub="1"
shower="1"/>
<Toilet
electronic_bidet="1"
mobility_accessible="1"/>
</BathAndToilet>
<OpenAirBath/>
<AirConditioning/>
<Balcony/>
<Views>
<LakeView/>
<MarinaView/>
<BeachView/>
<ForestView/>
<MountainView/>
<NatureView/>
</Views>
</RoomFeatures>
</RoomData>
</PropertyDataSet>
</Transaction>
Two double beds
The following is an example of western
style room with two double
beds.
<?xml
version="1.0"
encoding="UTF-8"?>
<Transaction
timestamp="2023-07-23T16:20:00-04:00"
id="42">
<PropertyDataSet>
<Property>1234</Property>
<RoomData>
<RoomID>RoomID_1</RoomID>
<RoomFeatures>
<JapaneseHotelRoomStyle>western</JapaneseHotelRoomStyle>
<Beds>
<!--
Two
double
beds-->
<Bed
size="double"></Bed>
<Bed
size="double"></Bed>
</Beds>
</RoomFeatures>
</RoomData>
</PropertyDataSet>
</Transaction>
Japanese style without bed
The following is an example of a Japanese style room without bed. Bed
information is not required for japanese
style room.
<?xml
version="1.0"
encoding="UTF-8"?>
<Transaction
timestamp="2023-07-23T16:20:00-04:00"
id="42">
<PropertyDataSet>
<Property>1234</Property>
<RoomData>
<RoomID>RoomID_1</RoomID>
<RoomFeatures>
<JapaneseHotelRoomStyle>japanese</JapaneseHotelRoomStyle>
</RoomFeatures>
</RoomData>
</PropertyDataSet>
</Transaction>
Japanese western w/bed
The following is an example of a japanese_western
style room with king
size bed.
<?xml
version="1.0"
encoding="UTF-8"?>
<Transaction
timestamp="2023-07-23T16:20:00-04:00"
id="42">
<PropertyDataSet>
<Property>1234</Property>
<RoomData>
<RoomID>RoomID_1</RoomID>
<RoomFeatures>
<JapaneseHotelRoomStyle>japanese_western</JapaneseHotelRoomStyle>
<Beds>
<Bed
size="king"></Bed>
</Beds>
</RoomFeatures>
</RoomData>
</PropertyDataSet>
</Transaction>
If partner doesn't have the number of beds information in japanese_western
rooms, then refer to the following example:
<?xml
version="1.0"
encoding="UTF-8"?>
<Transaction
timestamp="2023-07-23T16:20:00-04:00"
id="42">
<PropertyDataSet>
<Property>1234</Property>
<RoomData>
<RoomID>RoomID_1</RoomID>
<RoomFeatures>
<JapaneseHotelRoomStyle>japanese_western</JapaneseHotelRoomStyle>
</RoomFeatures>
</RoomData>
</PropertyDataSet>
</Transaction>
Meals
The following example defines room and package metadata for meals, photos, and check-in and check-out times:
<?xml
version="1.0"
encoding="UTF-8"?>
<Transaction
timestamp="2017-07-18T16:20:00-04:00"
id="42">
<PropertyDataSet>
<Property>1234</Property>
<PackageData>
<PackageID>PackageID_1</PackageID>
<Name>
<Text
text="Meals
Included"
language="en"/>
</Name>
<PhotoURL>
<Caption>
<Text
text="Breakfast"
language="en"/>
<Text
text="朝食"
language="ja"/>
</Caption>
<URL>http://example.com/static/bar/image1234.jpg</URL>
</PhotoURL>
<Meals>
<!--
Guests
can
choose
to
have
breakfast
in
their
room
or
in
another
space
to
avoid
contact
with
other
guests.
-->
<Breakfast
included="1"
in_room="1"
in_private_space="1"/>
<Dinner
included="1"
buffet="1"/>
</Meals>
<CheckinTime>15:00</CheckinTime>
<CheckoutTime>11:00</CheckoutTime>
</PackageData>
</PropertyDataSet>
</Transaction>
Breakfast only
<?xml
version="1.0"
encoding="UTF-8"?>
<Transaction
timestamp="2017-07-18T16:20:00-04:00"
id="42">
<PropertyDataSet>
<Property>1234</Property>
<PackageData>
<PackageID>PackageID_1</PackageID>
<Name>
<Text
text="Breakfast
Included"
language="en"/>
</Name>
<PhotoURL>
<Caption>
<Text
text="Breakfast"
language="en"/>
<Text
text="朝食"
language="ja"/>
</Caption>
<URL>http://example.com/static/bar/image1234.jpg</URL>
</PhotoURL>
<Meals>
<Breakfast
included="true"/>
<!--
Dinner
not
included
needs
to
be
explicitly
specified
-->
<Dinner
included="false"/>
</Meals>
<CheckinTime>15:00</CheckinTime>
<CheckoutTime>11:00</CheckoutTime>
</PackageData>
</PropertyDataSet>
</Transaction>
Responses
Syntax
The TransactionResponse (Property Data)
message uses the following syntax:
<?xml
version="1.0"
encoding="UTF-8"?>
<TransactionResponse
timestamp=" timestamp
"
id=" message_ID
"
partner=" partner_key
">
<!--
Either
Success
or
Issues
will
be
populated.
-->
<Success/>
<Issues>
<Issue
code=" issue_code
"
status=" issue_type
"> issue_description
</Issue>
</Issues>
</TransactionResponse>
Elements and attributes
The TransactionResponse (Property Data)
message has the following
elements and attributes:
Element / @Attribute | Occurrences | Type | Description |
---|---|---|---|
TransactionResponse
|
1 | Complex element | The root element indicating the success or issues for a received Transaction request message. |
TransactionResponse / @timestamp
|
1 | DateTime | The creation date and time of this message. |
TransactionResponse / @id
|
1 | string | The unique identifier from the associated Transaction message. |
TransactionResponse / @partner
|
1 | string | The partner account for this message. |
TransactionResponse / Success
|
0..1 | Success | Indicates that the Transaction message was processed successfully
without warnings, errors, or failures. Either |
TransactionResponse / Issues
|
0..1 | Issues | A container for one or more issues encountered while processing the
Transaction message. Either |
TransactionResponse / Issues / Issue
|
1..n | Issue | The description of a warning, error, or failure encountered while processing the Transaction message. Details on these issues can be found in Feed Status Error Messages . |
TransactionResponse / Issues / Issue / @code
|
1 | integer | The identifier for the issue. |
TransactionResponse / Issues / Issue / @status
|
1 | enum | The type of issue encountered. Valid values are |
Examples
Success
The following is a response to a successfully processed Transaction message.
<?xml
version="1.0"
encoding="UTF-8"?>
<TransactionResponse
timestamp="2020-05-18T16:20:00-04:00"
id="12345678"
partner="partner_key">
<Success/>
</TransactionResponse>
Issues
The following is a response to a Transaction message not processed due to errors.
<?xml
version="1.0"
encoding="UTF-8"?>
<TransactionResponse
timestamp="2020-05-18T16:20:00-04:00"
id="12345678"
partner="partner_key">
<Issues>
<Issue
code="1001"
status="error">Example</Issue>
</Issues>
</TransactionResponse>