# Technical Overview #### Service ARI (Availability, Rates, and Inventory) changes can be pushed to RG Bridge in real-time. In the push model, information is sent (pushed) by the system where the information originated. In contrast, in the pull model, the system needing the information periodically connects to access it. The push model's advantage for the PMS (Property Management System) is that it doesn't need to track all changes since the last pull. #### Communication Protocols The exchange of information between RG Bridge and PMS occurs through REST messages.

#### General Design **Availability and Rates Notification Service**: * **Operations**: 1. **Updating Inventory, Availability, and Restrictions**: * **OTA Messages**: * **Request**: `OTA_HotelAvailNotifRQ` * **Response**: `OTA_HotelAvailNotifRS` 2. **Updating Rates (Base by GuestAmount and AdditionalGuestAmount)**: * **OTA Messages**: * **Request**: `OTA_HotelRateAmountNotifRQ` * **Response**: `OTA_HotelRateAmountNotifRS` #### Authentication * **Basic Authorization**: All request messages exchanged between the PMS and RG Bridge must use basic authorization. * **Credentials**: Username and password need to be passed using basic authentication in HTTP headers. * **Authorization Example**: ``` Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ= ``` * **Content-Type**: `text/xml` #### Hotel Product Handling * **Differences in Categorization**: There may be substantial differences in how RG Bridge categorizes hotel products compared to the PMS structure. * **Understanding Differences**: It's crucial to understand these differences to ensure successful integration.
**RG Bridge** defines hotel products as a combination of a room type and a rate type. A hotel can have many room types and rate types. * **Rate Types Categorization**: PMS systems typically classify rate types into different categories or segments. * **Translation Requirement**: The PMS must translate updates at the level of rate segments/rate categories into either room type level updates or product level updates before sending them to RG Bridge. **Example**: If a PMS user updates the availability of the rate segment (Corporate Rate A) by changing the maximum available inventory count from 25 to 15, the PMS must: 1. Determine all room type-rate type combinations affected by this change. 2. Generate separate updates for each combination. This design minimizes the effort required by the hotel to keep the inventory structure synchronized between the PMS and RG Bridge. #### Reliability Mechanisms and Constraints **Single Hotel Specification**: * Only one hotel can be specified in a request message. **Multiple Room Types Update**: * Multiple room types for the same hotel can be updated in one message exchange. **Rate Type Handling**: * If a rate type is not specified along with the room type in an update, the update is applied to all products defined for that room type. **Volume of Messages**: * Due to the high volume of messages exchanged between RG and the PMS, it is essential to implement the reliability mechanisms and constraints described in Table B. | **Type** | **Mechanism/Constraint** | **Description** | | -------------------------- | ------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Retry | Retry strategy for communication Failure and in case of specific errors returned in XML response | The Systems and PMS will have a retry mechanism in place for communication errors and business error. | | Concurrency | Simultaneous connections per property <= 1 | PMS RG Interface will establish a single connection per Property at any given time for updating the ARI events, and allows only one Connection per Property at a time for receiving the Booking Notifications. | | Timeout |

Time out after 60,000

milliseconds (1 minute)

|

Idle connections (no packets sent by either side) for

more than 1 minute are closed. These should be considered as incomplete and implement are try strategy to re-send data.

| |

Character

Set

| Support for UTF-8 | All messages exchanged must have UTF-8 encoding | | Hotels | Onlydatarelatedtoone hotel can be sent in a single request message |


| | Room Types |

Maximum number of

room types in a single request message must be less than 10

|


| | Rate Types | Maximum number of rate types in a single request message must be less than 10 |


| | Date Range | 366 Days | Maximum number of days that a single request message could update must not exceed 366 days. | |

Message

Size

| 400 KB | Maximum size for a single message must not exceed 400 KB. | --- # Agent Instructions: 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/our-products/channel-manager/rg-bridge-supply-push/interface-specifications-availability-and-rates-notification-service/technical-overview.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.