Booking Push/Ping - API

Real-time booking notifications.

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

Whenever a new WebHotelier booking, 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 bookings 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 booking. Multiple affected bookings 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 booking body to your endpoint URL. We support both JSON and XML.

Your system must store the booking 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 booking as synced on our system. No other action is required from your side.

JSON Request Shema

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

XML Request Shema

<response>
  <id>INTEGER</id> // WebHotelier Confirmation Number
  <type>STRING</type> // "new" or "update" or "cancel" or "restore" or "transaction"
  <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 booking is cancelled as a whole.

Changes in rooms amount are sent as modifications.

Queues

If your system can quickly store the booking 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 bookings 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" booking with a previously imported confirmation number (id).