# Technical overview

## Service Model

**Connected Model**:

* This interface is designed to be used in a connected model where partner systems should always be available to receive reservations.

**Push-Model Web Service**:

* As part of the integration, CRS/PMS partners should develop a push-model web service that meets the described standards and make it available to RG Bridge.
* In the push model, information is sent (pushed) by the system on which the information originated.

**Pull Model**:

* In contrast, the pull model involves the system that needs the information accessing it by periodically connecting to it.

**Advantages of the Push Model**:

* The push model eliminates the need for partners to periodically access RG Bridge to check for new reservations, ensuring seamless and real-time updates.

### General design

<figure><img src="/files/4aAlQ6jRoMxc3dMN6V1c" alt=""><figcaption></figcaption></figure>

<br>

**Primary Operation**:

* **Reservation Notifications**: RG Bridge will send reservations downloaded from OTAs to PMS using reservation notification request messages.
  * Each reservation notification request will hold a single reservation record.
  * PMS will respond with either:
    * A **success response** with a PMS confirmation code.
    * An **error response** with reasons for failure.

**Message Exchange**:

* **New, Modified, and Canceled Reservations**: All are pushed by sending `OTA_HotelResNotifRQ` messages and receiving `OTA_HotelResNotifRS` messages in response.

This streamlined process minimizes the effort required by the PMS to implement the services, ensuring efficient and accurate handling of reservation notifications.

## Connectivity Mode

**Connectivity**:

* The connectivity supports REST communication mode for exchanging messages between the RG Bridge interface and partner system.

**REST Connectivity**:

* Clients have the option of implementing HTTP Basic Authentication for message exchange.
  * **Service Credential**: Username and password need to be passed using basic authorization in HTTP headers.

Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ= &#x20;

The Content-Type used as text/xml.

### Reservation Handling

It's crucial to grasp how RG Bridge processes reservations to ensure a successful integration with your PMS.

#### Split versus Non-Split Reservation Delivery

**Split Mode**:

* Partners opting for split mode configuration will receive split/leg reservation messages per room count booked in a reservation.
* **Example**: If a reservation is booked for 2 rooms, the partner will receive:
  * ResvID#1(1/2)
  * ResvID#1(2/2)
  * Each with different confirmation numbers returned from the partner in response.

**Full Mode**:

* In full mode configuration, only 1 reservation is delivered containing all room information in a single message.
* This reservation will be saved using the same confirmation number in the partner system.

#### Cancellation against Modification

**OTA Handling**:

* OTAs handle reservation modifications in various ways. Many use the “Cancellation against Modification” (CAM) process, where modifications are delivered as a pair of Cancel and New reservations.
* Some OTAs might deliver modifications directly without the CAM process.

**PMS Handling**:

* The PMS should be capable of handling both methods of modification (CAM and direct modifications).

This flexibility ensures that the reservation delivery system can accommodate different scenarios, providing accurate and efficient reservation management

### Reliability mechanisms and constraints.

Given the high volume of messages exchanged between the RG Bridge and the PMS, it is essential to implement the mechanisms and constraints described in Table B to ensure efficient and reliable communication.

**Reliability mechanisms and constraints**

| **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                                                                                                                                                                                                                                                          |
| <p>Reservation</p><p>Information</p> | Support reservations accept reservations with minimum information                                | There is great variation in the structure and amount of information available in reservations retrieved from OTAs. The PMS should be able to process reservations with the minimum amount of information.                                                                                                |
| <p>Reservation</p><p>Information</p> | <p>Support reservations delivered to DEFAULTROOM</p><p>and DEFAULTRATE</p>                       | Occasionally, reservations would be retrieved from OTAs which cannot be mapped to any existing room/rate types on RG Bridge. RG Bridge will deliver these reservations with Room type code set to “DEFAULTROOM” and Rate Type code set to “DEFAULTRATE”. PMS should be able to accept such reservations. |
| <p>Payment</p><p>Information</p>     | <p>Support one-time delivery of</p><p>credit card information</p>                                | To comply with PCI standards, many OTAs and consequently RG Bridge, deliver credit card information only once. PMS should be able to accept modifications and cancellations of reservations without credit card information.                                                                             |


---

# 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-reservation-notification-service/technical-overview.md?ask=<question>
```

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.