Real-time reservation notifications for WebHotelier bookings.

Table of Contents
  1. Endpoint Registration
  2. PING mode
  3. PUSH mode

Whenever a new WebHotelier reservation, modification, or cancellation is made our system can call a 3rd-party endpoint in real-time.

The endpoint is registered in WebHotelier's API account settings.

Endpoint Registration

To enable real-time notifications you need to provide us with the following:

NAME DESCRIPTION REQUIRED NOTES
endpoint Internet accessible URL YES A secure ( HTTPS ) endpoint is required
mode PUSH or PING YES explained below
format JSON or XML YES JSON is recommended
username NO HTTP Authentication
password NO HTTP Authentication

Only required when mode is PUSH.


PING mode

This is a simple GET request. We register your endpoint and call it. It is recommended to use a universal endpoint for all your connected properties, and utilize x-wh-property header to determine the requested property.

Custom Headers

NAME TYPE RANGE / SET NOTES
x-wh-property string varchar(10) Property code for which reservations to be downloaded are pending

Request Flow

You are responsible for calling /reservation/new, retrieve new records and mark them as synced.

The process is as follows:

Caution

The entire mode of operation MUST be asynchronous.
If your system repeatedly delays to respond to the GET requests, your account may be banned.

Warning

In order to be notified as soon as possible, WebHotelier sends a notification per action per reservation. Multiple affected reservations are not batched in a single notification.

You should be ready to handle multiple notifications for the same property with very close interval, and always process the same property in a single-threaded mode, as recommended in List Pending Reservatons method.

Recommended

Because of its asynchronous nature, this mode of operation is recommended for general use.


PUSH mode

In PUSH mode, WebHotelier pushes the entire reservation body to your endpoint URL. We support both JSON and XML.

Your system must store the reservation body and return "200 OK". Any other response code is assumed an error.

Warning

Your system must store and acknowledge retrieval as soon as possible.

All post-processing actions on your side must be deferred.

Any long delays will be investigated.

As soon as we receive a "200 OK" we mark the reservation as synced on our system. No other action is required from your side.

Sample JSON response

{
  "id": INTEGER, // WebHotelier Confirmation Number
  "type": STRING, // "new" or "update" or "cancel"
  "data": OBJECT // the data element as returned from /reservation/{res_id}
}

Sample XML response

<response>
  <id>INTEGER</id> // WebHotelier Confirmation Number
  <type>STRING</type> // "new" or "update" or "cancel"
  <data>XML</data> // the data element as returned from /reservation/{res_id}
</response>

Note about cancellations

Partial cancellations are not supported by WebHotelier. The entire reservation is cancelled as a whole.

Changes in rooms amount are sent as modifications.

Queues

If your system can quickly store the reservation body in a queue, defer and reply immediately you should prefer this mode of operation instead of PING ( requires only 1, instead of 3 HTTP roundtrips ).

If you decide to use PUSH, you MUST also implement PULL. This allows you to recover from unsuccessful PUSH deliveries (e.g. server maintenance or connectivity problems). It also allows you to fetch any reservations that may have been imported to the sync-queue outside of the normal booking process.

Deduplication Warning

WebHotelier confirmation numbers are unique.

Your system should never accept a "new" reservation with a previously imported confirmation number (id).