Guidelines

In accordance with the API Services Terms of Use Agreement signed by the OTA partner before development has commenced, these guidelines are in place to ensure efficient and proper use of the SiteConnect API.

The following Integration Requirements MUST be adhered to by all OTAs that have or wish to have an interface to SiteConnect.

For OTA providers that have already been implemented, the below may require changes to the set-up they currently have. Whilst SiteMinder could be flexible in accommodating exceptions in the past, the constant increase in the number of OTA installations is reaching a level where exceptions can no longer be allowed.

Failure to follow these guidelines could jeopardise the OTA interface and, if no action is taken by the OTA provider to rectify non-compliance within three months from notification, SiteMinder reserves the right to disable the interface till such corrections have taken place. However, if the non-compliance of the OTA puts the performance to the whole SiteMinder production environment at risk, SiteMinder reserves the right to disable the interface immediately.

Security

SSL/TLS

SiteConnect supports TLSv1.1 and above. The production URI MUST implement the HTTPS protocol.

SiteMinder does NOT support self-signed SSL certificates.

Strong Password Policy

At least 8 characters—the more characters, the better. A mixture of both uppercase and lowercase letters and a mixture of letters and numbers. Better Inclusion of at least one special character, e.g.,! @ # ? ]

Application General

SOAP Message

All messages (Request/Response) between SiteConnect and Booking Channel must be SOAP Message. They include a SOAP Security header for authentication purposes and contain the SOAP Body which contains the OTA message.

Content-Type

The Content-Type for all Soap XML requests made to SiteConnect MUST be 'text/xml; charset=utf-8'. Any other Content-Type will not be accepted.

Endpoints

Partners should try to provide SiteConnect with a Single URI endpoint for all messages. If this is not possible, SiteConnect can handle a maximum of 2 URIs (one for the Retrieve Rooms API and one for the Inventory PUSH API).

Error Handling

It is expected that your application has a robust error handling process in place. The error handling process includes a queuing mechanism and a robust retry strategy. Refer to the Error Handling section of the SiteConnect documentation for more information.

HotelCode

HotelCode is the unique identifier provided by the Booking Channel . The HotelCode MUST be unique per property per Channel.

Reservation Regions

SiteConnect has two (2) regions for reservation delivery, APAC (Asia Pacific) and EMEA/AMERS (Europe, Africa, Middle East & Americas). Your connection should be able to facilitate sending reservations to different endpoints.

API General

EchoTokens

EchoTokens are essential for all requests (namely OTA_HotelResNotifRQ) being made over the SiteConnect. EchoToken MUST be unique per request. EchoTokens ensure that each request can be uniquely identified for troubleshooting purposes in both testing and production environments. All requests you receive from SiteConnect will contain an EchoToken, and the Booking Channel response MUST mirror the EchoToken as received in the request.

TimeStamp

The TimeStamp format must follow the ISO 8601 Date and Time formats. This profile defines two ways of handling time zone offsets:

1. Times are expressed in UTC (Coordinated Universal Time), with a special UTC designator ("Z").

2. Times are expressed in local time, together with a time zone offset in hours and minutes.
   A time zone offset of "+hh:mm" indicates that the date/time uses a local time zone which is "hh" hours and "mm" minutes ahead of UTC.
   A time zone offset of "-hh:mm" indicates that the date/time uses a local time zone which is "hh" hours and "mm" minutes behind UTC.

Line spacing

All Soap XML requests made to SiteConnect should be contained on one line with no line spacing or newline characters, the XML messages must be minified. We ask this to assist our support teams in extracting messages from our logs.

Example:

Integration

Mandatory Functionality

1. All SiteConnect connections MUST be a 2-way XML connection: push Inventory and receive Reservations.

2. SiteConnect will PUSH availability, restrictions and rates to the booking channel.

3. The booking channel will PUSH reservations to SiteConnect.

4. The following functionalities are Mandatory:

   1. Availability

   2. Stop Sell

   3. Reservation Delivery

SiteConnect API

There are 4 types of APIs included in the SiteConnect API set:

1. Room Retrieval API

2. Inventory Push API

3. Rate Push API

4. Reservation API

To have a better understanding of how these API works between the SiteConnect and Booking Channel, check the SiteConnect Technical Architecture Diagram.

Room Retrieval API

1. SiteConnect uses OTA_HotelAvailRQ to PULL a list of room rates available on the booking channel.

2. The booking channel MUST ensure only “active” room rates are returned in the OTA_HotelAvailRS.

3. Room and rate codes returned by the Retrieve Rooms API must avoid using any special characters, such as “<“, “>”, “&”, “““, ”'“. 

4. Rooms rates returned by the Retrieve Rooms API should contain a clear and concise RoomDescription (and RatePlanDescription when using both room and rate codes) to ensure SiteMinder hoteliers can quickly and easily map/link their SiteMinder room rates to your booking channel. Special characters, such as “<“, “>”, “&”, “““, ”'“ must be avoided in the RoomDescription/RatePlanDescription. If these characters are not able to be avoided, these characters MUST be escaped.

5. If Occupancy Based Pricing (OBP) is enabled, the booking channel MUST return “Occupancy” elements in the Room Retrieval API for all RoomType/Rateplan of all connected properties.

Inventory and Rate Push API

1. SiteConnect uses OTA_HotelAvailNotifRQ to PUSH availability and restrictions.

2. SiteConnect uses OTA_HotelRateAmountNotifRQ to PUSH rates.
   NOTE: SiteConnect will send the OTA_HotelAvailNotifRQ message first. Only after this message has received a successful response from the booking channel, the OTA_HotelRateAmountNotifRQ message will be sent.

3. SiteConnect will send updates on two (2) minute cycles.

4. The partner must always respond with either a “Success” or “Error” response. Under NO circumstances should a request be ignored and a response not sent.

5. Regardless of the change made within SiteMinder, SiteConnect will send both the OTA_HotelAvailNotifRQ and OTA_HotelRateAmountNotifRQ for the affected rooms and dates.

6. For performance reasons, SiteConnect expects ALL messages to receive a response from the partner within five (5) seconds. If a response is NOT received within a twenty (20) second timeframe, the request will timeout and the message will be re-queued to be sent again on the next update cycle.

7. The maximum update period SiteConnect can update is seven-hundred and fifty (750) days. The minimum update period is fourteen (14) days. We always recommend a buffer be in place on the partner side, especially if you are a last-minute booking site. I.e., if you only sell the next fourteen (14) days, the hotelier should be able to upload information a minimum of twenty-one (21) to thirty (30) days.

8. SiteConnect will bundle consecutive updates of the same values in seven (7) day bundles. 

9. It is important to remember the potential for large amounts of data to be pushed out from SiteConnect. If a hotel enables their connection, you can potentially receive seven-hundred and fifty (750) days worth of Availability, Restrictions and Rates all within a short space of time. If you have several properties go live simultaneously or push large updates, the data load can be pretty large. We urge that you complete stringent performance testing on your production servers/endpoint(s) to ensure they will scale with the number of hotels you'll have connected in production.

10. If your system does not have the concept of stop sells, the RestrictionStatus “Close” should be seen as zero (0) availability.

11. If Occupancy Based Pricing (OBP) is enabled, the booking channel must support the “Included occupancy”, “Extra Adult“ and “Single Guest Discount” features. If the included occupancy value is not set, the value will be sent to “2” as default.

Reservation API

1. Booking Channels use OTA_HotelResNotifRQ to PUSH reservations to the SiteConnect.

2. SiteConnect ONLY allows one (1) hotel code per reservation. If a partner allows multiple hotels per reservation, one (1) reservation per hotel MUST be sent.

3. SiteConnect ONLY allows one (1) reservation per request sent.

4. Reservation IDs (UniqueID ID) MUST be unique among all properties connected at all time. If a reservation is received with an ID already used, it will be ignored regardless if it arrives for a different hotel.

5. SiteConnect ONLY allows the maximum reservations booking days span is less than seven-hundred and fifty (750) days.

6. SiteConnect allows multiple rooms and rate plans in a single reservation request, as long as they are part of the same reservation.

7. SiteConnect has two (2) regions for reservation delivery, APAC (Asia Pacific) and EMEA/AMERS (Europe, Africa, Middle East & Americas). Your connection should be able to facilitate sending reservations to different endpoints.

8. By default, a booking channel will be deployed to both regions. Exceptions to be agreed upon with SiteMinder.

9. A SiteMinder hotelier can only exist in one (1) region.

10. If you choose to send through Payment Information, the @CardType and @CardCode attributes are not shown in the SiteMinder extranet and will be passed onto any Hotels PMS system should one support this functionality. 
    NOTE: While the @SeriesCode attribute is supported in the reservation message, the details of this attribute are discarded and not stored or passed through to the hotel due to PCI-DSS requirements. The details of this attribute are ONLY passed through when the booking channel decides to utilise the SiteConnect Reservation Email notification.

11. If you choose to use Virtual Credit Card (VCC), VCC details need to be updated according to changes of Modification or cancellation. 

12. SiteConnect follows the OTA reservation specification and allows a lot of information to be sent through regarding reservations. Not all of that information is mandatory for SiteConnect to be able to process the reservation. Refer to the Reservation API documentation for more information.

Reservation (Initial Delivery)

1. Creations will be identified by the ‘Commit’ @ResStatus.

2. The creations contain the full reservation data, as it stands at the creation has been made.

3. The CreateDateTime must reflect the time the reservation was created within the partner system

Reservation Modifications

1. Modifications will be identified by the ‘Modify’ @ResStatus.

2. The modification MUST contain the full reservation data, as it stands the modification has been made.

3. The LastModifyDateTime must reflect the time the reservation was modified within the partner system

Reservation Cancellations

1. Cancellations will be identified by the ‘Cancel’ @ResStatus.

2. The cancellation MUST contain the full reservation data, as it stands at the time of the cancellation.

3. The LastModifyDateTime should reflect the time the reservation was cancelled within the partner system
   NOTE:  Availability will NOT automatically be made available within SiteMinder when a cancellation message is received.

Certification

SiteConnect certification will be undertaken once the development of all functionality has been completed. It is important to note that testing (including negative testing) of all developed SiteConnect API functionality should be completed prior to certification. The certification process is conducted by the partner answering various questions related to the functionality that you have selected and the number of questions will vary depending on the functionality you are supporting. The certification process must be completed using information presented on the partner system, not the information presented within the partner SiteMinder test account. There is no restriction to the number of times a partner can attempt certification.

Once certification is completed, the results will be reviewed by SiteMinder’s Partner Integrations team. SiteMinder and the Partner Integrations team reserve the right to delay deployment to SiteMinder’s production environments until they are satisfied with the results.

For more details, check the SiteConnect Certification Guide.

Test Environment Access

SiteMinder will provide a SiteMinder test account for use during development. Test account access is only guaranteed during active development and should not be used for ongoing testing or for demonstration purposes. Upon completion of SiteConnect certification, the test account will be disabled.