> For the complete documentation index, see [llms.txt](https://developer.rategain.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.rategain.com/content/content-update/interface-requirements.md). # Interface requirements ### Connectivity options The following connectivity options are available to clients of the HCD XML Update Interface.


Connection Type	Hardware Requirements	Encryption	Other Requirements
HTTP (unsecured)	None	None	Connection to the Internet. Not recommended if sensitive information is to be transmitted. Unsecured HTTP is only available in non- production environments.
Client SSL (Internet based / HTTPS)	None	Software Based	SSL toolkit, RSA cipher license, connection to the Internet
VPN (Internet based)	IPSEC capable device	Hardware Based	Connection to the Internet
Frame Relay (Dedicated line)	Frame-relay capable router	Not Required	None

### SOAP envelope The SOAP Envelope houses the entire message structure to be delivered. It is made up of an optional Header element, and a required Body element. **Note**: RateGain has moved from an RPC based format to a document-literal format. Previous versions of this specification reflect the RPC based format so please be sure to note the differences in this version. The changes are minimal as noted below: Namespace updates (xmlns attributes in the \ element) Structure of the \ element
### SOAP header The SOAP Header element is the location of message meta-data. Information such as username, password, action code, and transaction ID are present in the various SOAP Header elements and attributes. Username and password will correspond to an account created on the RateGain customer portal (my.pegs.com). This account will need to be enabled for HCD updates via Web services in order for the messages to be processed. While the SOAP specification allows the Header to be an optional element, RateGain requires it to be present in each request. Further, the use of the ebXML:MessageHeader element, and the wsse:Security elements are also required. The following links point to the schema files for the ebXML:MessageHeader element and the wsse:Security element. Clients can reference these schemas to determine required elements and attributes. · · The following table illustrates specific values that should be present in these elements.


Element	Attribute	R / O / C	Usage	Description
MessageHeader		R
	SOAP-ENV:mustUnderstand	R		Indicates “true” or “false”
	version	R	2.0	Indicates the ebXML version
From		R
PartyId		R		Supplier Name
To		R
PartyId		R	RateGain
CPAId		R	HCDUpdateInterface	The destination system
ConversationId		R	some value	This value can be used by the client to group a set of transactions into a “conversation”
Service		R	HCDUpdateInterface	The destination service
	type	R	4.0	Defines the version of the eb:Service element
Action		R	Add Update Upsert Delete	Defines the action to be performed on the property
MessageData		R
MessageId		R		Unique Record ID
Timestamp		R
Security		R		Defines the wsse Security element
UsernameToken		R		Defines the UsernameToken element
	Username	R	user name	The client’s username will be defined by RateGain


Element	Attribute	R / O / C	Usage	Description
	Password	R	password	The client’s password will be defined by RateGain

### SOAP body The SOAP Body contains the message payload. In the case of the HCD XML Update Interface, this is an OTA\_HotelDescriptiveContentNotifRQ OTA XML document. ### Example of SOAP envelope The following example SOAP Envelope shows the use of the ebXML Header and wsse Security elements within the SOAP Header. ``` Customer RateGain ODDUpdateInterface SIHtoODD1 ODDUpdateInterface UPSERT IDTPAPA 2024-10-15T13:01:31 RateGain assigned interface email address RateGain assigned password . . . ``` ### Action codes The action codes are defined in the SOAPHeader/eb:MessageHeader/eb:Action element. These codes, in conjunction with the “overwrite” and “removal” flags within the OTA\_HotelDescriptiveContentNotifRQ element, define what will happen to the property data within the message. The supported action codes are: Add, Update, Upsert, and Delete. ### Add An action code of “Add” is equivalent to a database “insert.” If the action code is “Add”, all required elements and attributes must be present in the OTA\_HotelDescriptiveContentNotifRQ message. If the message fails validation, an error will be returned to the client, and no data will be stored. If the action code is “Add”, and the property is found to exist in the HCD, an error will be returned, and the property data will not be modified. When a property is being added to the HCD, it must contain a minimum set of data elements in order to be considered valid. The following table describes these data requirements.


Element	Attribute
OTA_HotelDescriptiveContentNotiflRQ
	Version
	PrimaryLangID
HotelDescriptiveContents
HotelDescriptiveContent
	BrandCode
	HotelCode
	CurrencyCode
	HotelName
HotelInfo
	HotelStatus
	HotelStatusCode
CategoryCodes
LocationCategory
	Code
SegmentCategory
	Code
HotelCategory
	Code
Services
Service
	Code
	ProximityCode
FacilityInfo
GuestRooms


Element	Attribute
GuestRoom
	ID
Amenities
Amenity
	RoomAmenityCode
Policies
Policy
PolicyInfo
	CheckInTime
	CheckOutTime
	UsualStayFree CutoffAge
	KidsStayFree
TaxPolicies
TaxPolicy
	Percent
	Amount
	ChargeUnit
	Code
AreaInfo
Attractions
Attraction
	AttractionCategoryCode
	Code
	ID
ContactInfos
ContactInfo
Addresses
Address
	UseType
AddressLine
Cityname
StateProv
	StateCode
Countryname
	Code
Phones
Phone
	PhoneLocationType
	PhoneTechType
	Phonenumber

### Update An action code of “Update” is equivalent to a database “update”. If the action code is “Update” and the property is not found to exist in the HCD, an error will be returned to the client. Messages with an action code of “Update” will examine the “overwrite” and various “removal” flags that can be present in the OTA message structure to determine what course of action to take with the data in the request. When the “overwrite” attribute in the HotelDescriptiveContent element is set to “true” (false is assumed if the attribute is not present) it causes a “refresh” of the data to occur. This means that ALL property data will be removed and re-inserted with the data in the request transaction. Any child “removal” attributes will be ignored. Care must be taken to ensure that the resulting property record continues to meet the minimum required data elements as defined by RateGain. If this is not the case, an error will be returned, and the property data will not be updated. The “removal” attribute will work in a similar way. Any “removal” attribute that is set to “true” (false is assumed if the attribute is not present), causes the property data at that element level to be removed. This means that any data in the element containing the “removal” attribute, AND all the data of that element’s children, will be removed. Again, care must be taken to ensure that the resulting property record continues to meet the minimum required data elements as defined by RateGain. If this is not the case, an error will be returned, and the property data will not be updated. Sample of an Update message with Removal Flag = true: ``` ``` ### Upsert An action code of “Upsert” is equivalent to a database “Update” or “Insert”. If an action code is “Upsert”, a search for the property’s information will be performed. If the property is found, the data contained in the “Upsert” message will be used to update the HCD. If not found and the minimum required data set is not met, an error will be returned to the client. If the minimum required data set is met, then the property will be added to the HCD. Please refer to the action code of “Update” for the guidelines of the “Overwrite” and “Removal” flags. ### Delete An action code of “Delete” is equivalent to a database “delete”. If the action code is “Delete”, only the following attributes will be validated:


Element	Attribute
OTA_HotelDescriptiveContentNotifRQ


	Version
	PrimaryLangID
HotelDescriptiveContents
HotelDescriptiveContent
	BrandCode
	HotelCode

All other elements and attributes, including those of the HotelDescriptiveContent element, will be ignored. If the action code is “Delete”, and the property is not found in the database, an error will be returned to the client. When sending an action code of Delete, the property will be deleted for all languages when the primary language code = EN (English). When sending an action code of Delete and the language code is not EN (English), only the data associated to the provided language code will be deleted. ### Standard element formats ### Date and time All references to Date, Time and Timestamp will use the format required by the OpenTravel Specification, which follows ISO standard 8601: **Date:** The Date will be the Calendar Date format represented as \[YYYY]-\[MM]-\[DD] where \[YYYY] indicates a four-digit year, 0000 through 9999, \[MM] indicates a two-digit month of the year, 01 through 12, and \[DD] indicates a two-digit day of that month, 01 through 31. Example: 2024-10-15 **Time:** The Time will be the 24-hour clock (extended format) represented as \[hh]:\[mm]:\[ss] where \[hh] refers to a zero-padded hour between 00 and 24 (where 24 is only used to notate midnight at the end of a calendar day), \[mm] refers to a minute between 00 and 59, and \[ss] refers to a second between 00 and 59. Example: 22:59:01 **Timestamp** The Timestamp will be a combination of date and time represented as \[YYYY]-\[MM]-\[DD]T\[hh]:\[mm]:\[ss] where the time designator \[T] is used to show the start of the time component. Example: 2024-10-15T17:59:01 ### Specifications for currency amounts Only positive currency amounts are allowed within the message. Negative currency amounts are not allowed therefore will generate an error if present within any of the amount attributes. Positive amount · Positive ten U.S. dollars would appear in the message as: 10.00 ### Specifications for decimal amounts RateGain uses the Decimal Fixed Point for all decimal usages. In fixed-point numbers, DECIMAL(p,s), the decimal point is fixed at a specific place, regardless of the value of the number. When you specify a column of this type, you write its precision (p) as the total number of digits it can store, from 1 to 32. You write its scale (s) as the total number of digits that fall to the right of the decimal point. All numbers with an absolute value less than 0.5\*10-s have the value zero. The largest absolute value of a variable of this type that you can store without an error is 10p-s - 10-s For example: 5,2 will allow the following values – 12345 or 123.45 ### General business rules Business Rules are specific rules defined by RateGain that further clarify the use of a particular element and/or attribute within the OpenTravel XML message. The following rules apply to transactions submitted to RateGain: · Any Elements and/or Attributes present in the message that are not defined within this document will be ignored by RateGain. o One exception – Text Element under descriptions will only be allowed once, even if the parent element is not expected by RateGain. · Unless otherwise specifically stated within the document the OpenTravel schema definitions, limitations, and usage will be enforced. · Only English based property information will be distributed to the GDSs. · Enforcement of English as the first message received for action code of Add. If English is not the first message processed for an Add, all records for the property will be rejected until English is the first message received within a Transactional message or Batch. · All amount attributes are assumed to be in the property’s native currency. · When sending the Feature element, the parent element Service must contain the Code attribute of 47 (equals Accessible Code) or 80 (equals Security). If not present, an error will be returned and no information will be updated. · Within the Feature element, upon providing Physically Challenged (Feature/@AccessibleCode) or Security (Feature/@SecurityCode) information, only one of these code types should be present. If both are present, an error will be returned and no information will be updated. Multiple Feature elements may be sent in the same message to update more than one of these information types. · Within the Service element, upon providing Hotel Amenity (Service/@Code), Business Services (Service/@BusinessServiceCode), or Meal Plan (Service/@MealPlanCode) information, only one of these code types should be present. If more than one of these is sent, an error will be returned and no property information will be updated. Multiple Service elements may be sent in the same message to update more than one of these information types. · Default information will be applied in HCD for specific OpenTravel Hotel Amenities, Room Amenities, Business Services and Recreation facilities based on the description of the code in the OpenTravel code list. The three types of default are as follows: o Whether it is on-site or offsite. For example, if Hotel Amenity HAC.64 (On-site parking) is provided, the amenity will always be recorded as on-site in HCD (i.e. the same as setting Service/@Proximity=”1”). HCD will ignore any other value of Proximity that may be supplied. o Whether it is always complimentary or whether charges can be specified. For example, if Business Service BUS.52 (Incoming fax complimentary) is provided, RateGain will automatically set this service to be complimentary (Service/@Included=”true”) and will ignore any charges that may be supplied. o Whether operating times/schedules can be specified. For example, if Hotel Amenity HAC.33 (Elevators) is supplied, any operating schedules will be ignored because they are not appropriate for this type of amenity. Refer to the “HCD OTA Supported Codes” spreadsheet for the defaults that will be applied for specific codes in the HAC, RMA, BUS and RST code lists. · If Attraction/@AttractionCategoryCode is of type “Airport”, then Attraction/@Code must contain the corresponding three letter airport code. This is the only manner in which the attribute Code will be used. · All free form text fields allow bulleted lists. · The following elements contain an attribute labeled ID. This is a unique identifying value assigned by the creating system. The ID attribute will be used to reference a primary-key value within our database. o Attraction o GuestRoom o MeetingRoom o Restaurant o CancelPenalty (\*\*\*Note: attribute is labeled PolicyCode\*\*\* · At minimum, one RoomAmenityCode is required per each GuestRoom. · The Code attribute under the GuestRoom element can be used to group amenities that are not specific to an individual GuestRoom. RateGain supports use of the codes ALL and SOME under the Code attribute. When the Code equates to ALL or SOME, this will identify that the amenities are found in ALL rooms or SOME rooms. When the Code does not equal ALL or SOME, the amenities will only be associated with the specified guest room. · The OpenTravel codes are only allowed once per property unless otherwise specified within the usage of the attribute. · The PrimaryLangID attribute denotes the language that the data within the rest of the message. The following rules will apply to PrimaryLangID: o When sending an action code of Delete, the property will be deleted for all languages when the primary language code = EN (English) o When sending an action code of Delete and the language code is not EN (English), then only the data associated to the language will be deleted. · Chain, Brand, and PID codes must be sent in upper case. · HotelStatusCode attribute allows the status of 5 (Test). “Test” properties will be excluded from all HCD content extracts and will only be accessible by distributors when the exact brand and PID are included within the request. · HotelStatusCode attribute allows the status of 3 (PreOpening). RateGain will ignore the HotelStatus attribute (Bookable / NonBookable flag) and default to NonBookable. This will allow the property to be visible but not receive booking request. · When the Action code is Add the Overwrite and Removal attributes are ignored. · There can be multiple GuaranteePayment policies per property, but only one for each GuaranteeCode within a specified date range is allowed. · The ExistsCode attribute is used to help determine if an “amenity” code is available at the property. When the ExistsCode attribute equals 1, RateGain will include the “amenity”. When the ExistsCode attribute does not equal 1, the “amenity” will not be added. If the client chooses to not use this attribute or leave this attribute empty, RateGain will add all “amenities” associated to the empty attribute. · When providing an update message to modify the address (specifically AddressLine attribute) information, all previous AddressLine must be provided including the line which includes the modified piece of data. For example, if 5 lines were previously provided, then all 5 lines will need to be provided to update the AddressLine data. · At least one property phone number is required with a PhoneLocationType=”4” and a PhoneTechType=”1”. · The Removal flag found under ContactInfo element will only apply to removal of the phone data found under the Phone element. · A property status to Delete will not be able to be modified. Please contact your RateGain representative to update the property from a delete status. · A property status to Sanctioned will not be able to be modified. Please see section 2.8 for more details or you may contact your RateGain representative for further details. · TimeZone attribute houses the information for both the time zone and GMT offset. RateGain allows for each individual piece of information to be submitted together using a semi-colon between the two or sent individually. However, when only sending the GMT offset the semi-colon is needed and must be the first character. · Effective dates (Start, End and DOW) for Guarantee Payment Policies with the same GuaranteeCode value may not overlap. RateGain will return an error if two or more Guarantee Payment policies are sent with same date range & DOW, or an update sent would result in an overlap. o For example: If a policy is sent for 10/15/2024 through 12/31/2024 for Monday through Friday, a second policy may be sent for the same date range for Sat and Sun, but the same date range with the same Days of Week will not be allowed. · The Guarantee Deposit Policy date ranges are independent of the Method of Payment Policy date ranges. · End date under the Guarantee Payment cannot be before the Start date. · Basic child policies, such as “1 child aged 12 or under allowed free per adult” can be defined using structured fields using the element HotelDescriptiveContent/Policies/Policy/PolicyInfo. However, if more complex child policies are required – such as “1 child aged 12 or under allowed free for every 2 paying guests up to a maximum of 2 free children” then the child policy can be extended using the TPA extension: HotelDescriptiveContents/TPA\_Extensions/TPA\_Extension/ChildPolicyExtended. The ChildPolicyExtended element is intended to supplement the basic child policy information in PolicyInfo, not to replace it. ### Special characters and trademarks #### Special Characters With the allowance of multi byte languages, special characters will also be supported in HCD. Special characters can range from the simple umlaut to more complex character sets. The following link is to the Unicode Code Chart for Symbols and Special Punctuation (special characters). Suppliers can reference this site to determine the requirements for each character. Suppliers will need to modify their process to match the HTML Unicode Standards. The standard for sending special characters to RateGain is as follows: \ode;. Using the charts found in the above link, suppliers will be able to ascertain the "code" value for a special character. For more information, the following link contains the guidelines on the use of the Unicode standard in conjunction with the XML. #### Trademarks It is the responsibility of the hotel company inputting data into the HCD to ensure that trademarks used are authorized for use by their owners prior to input. #### AAA Trademark Usage Input of the American Auto Association (AAA) trademarks and references to diamond ratings are prohibited by AAA. Messages containing any reference to AAA will be returned as an error to the supplier. None of the data in that message will be processed. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://developer.rategain.com/content/content-update/interface-requirements.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.