The reservation pull delivery model involves the use of 4 OTA messages in 2 request/response exchanges, both initiated by the PMS.

The reservation pull process begins with the PMS sending an OTA_ReadRQ message to PmsXchange and being returned an OTA_ResRetrieveRS. The main payload contents of the OTA_ResRetrieveRS message are HotelReservation elements which contain the details of zero or more reservations. The PMS is expected to process these and then confirm delivery by sending an OTA_NotifReportRQ message to PmsXchange. In response to this message PmsXchange will return an OTA_NotifReportRS message.

Please refer this page for an overview of the reservation delivery process (OTA_ReadRQ ↔  OTA_ResRetrieveRS & ← OTA_NotifReportRQ) - PMS Technical Architectural Diagram

Important Notes

Delivery confirmation is essential

Each reservation retrieved from PmsXchange must be confirmed as delivered, even if the PMS could not process it successfully. For example, the PMS might not be able locate the room type referred to in the reservation or no rooms are available. If a reservation could not be successfully processed then there is a mechanism to inform PmsXchange about this using the normal delivery confirmation message - OTA_NotifReportRQ. If reservations are not confirmed as delivered they will continue to be pulled with each OTA_ReadRQ sent by the PMS.

Delivery confirmation batching

It is NOT a requirement that all the reservations retrieved in a single pull by the PMS be confirmed in one OTA_NotifReportRQ message. If it is more practical for the PMS to send one OTA_NotifReportRQ for each reservation, then this is acceptable.

Confirming Reservations which could not be processed by the PMS

As mentioned above, even reservations which are not successfully processed by the PMS must be confirmed as delivered. The OTA_NotifReportRQ structure does not allow for a mixture of successfully and erroneous reservations to be confirmed together. Successfully processed reservations must be confirmed as delivered in OTA_NotifReportRQ messages separate from those that could not be processed.