Open Travel Alliance (OTA)

The Open Travail Alliance offers a broad variety of XML messages that allow technology partners to interace with each other. Voluntarily the current documentation limits itself to the most commonly used message formats. Additional messages might be available upon demand.

How to use OTA:

OTA messages are structured logically. The root element of every message will indicate what the purpose of the message is. For example OTA_HotelInvCountNotifRQ tells you the following

A XML message structured according to the OTA specifications (OTA_HotelInvCountNotifRQ)
Within the OTA specifications, it is within the hotel scope (OTA_HotelInvCountNotifRQ)
Within the OTA/hotel scope, it concerns the inventory count (OTA_HotelInvCountNotifRQ)
The sender is seeking to notify the receiving system of changes (OTA_HotelInvCountNotifRQ)
This is a request coming from the sender (OTA_HotelInvCountNotifRQ)

Even though there are some rare exceptions every OTA_Hotel...RQ request has its corresponding response OTA_Hotel....RS

Communication using OTA messages is intended to by synchronuous. Meaning that on sending a request, the response should come immediately and confirm/disconfirm if the request could be executed properly. An exception exists for the reservation polling/confirming as described below.

Data flow

All the OTA message containing "Notif" imply that the third party software client pushes/notifies information to the Hotel-Spider servers.

The other messages are there to interogate the Hotel-Spider system

OTA_HotelResNotifRQ/OTA_HotelResNotifRS

An exception exists with the OTA_HotelResNotifRQ / OTA_HotelResNotifRS request pair when evolving in a nonsynchronous solution. In this case, the OTA_HotelResNotifRQ is used as a response to the OTA_ReadRQ interogation followed by a second request where the OTA_HotelResNotifRS provides the required feedback to the Hotel-Spider servers.

Implemented OTA messages:

The list below shows the different OTA messages Hotel-Spider can cope with. It is NOT expected that third party providers implement all the different messages. The appropriate uses of the different messages are explained on the individual documentation pages. Whenever possible a third party software provider is encouraged to re-use previous developments.

Re-using existing developments:

Being a broadly used as protocol, a lot of third party software provider probably already have implemented several OTA messages. Examples of previous implementations that could be re-used:

Booking.com OTA interface

Versions implemented:

2009A (Legacy version. Should not be used for new implementations)
2014A

Upcoming implementations:

N/A