Real-time booking notifications.
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.
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.
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.
NAME | TYPE | RANGE / SET | NOTES |
---|---|---|---|
x-wh-property | string | varchar(10) | Property code for which bookings to be downloaded are pending |
You are responsible for calling /reservation/new, retrieve new records and mark them as synced.
The process is as follows:
The entire mode of operation MUST be asynchronous.
If your system repeatedly delays to respond to the GET
requests, your account may be banned.
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.
If you decide to use PING, you MUST also implement scheduled PULL. This reduces the risk of losing bookings in case of unsuccessful delivery, 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. A PULL interval of 1 hour is recommended for low traffic properties. Adjust for high traffic properties or according to your needs.
Because of its asynchronous nature, this mode of operation is recommended for general use.
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.
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.
{ "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} }
<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>
Partial cancellations are not supported by WebHotelier. The entire booking is cancelled as a whole.
Changes in rooms amount are sent as modifications.
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 reduces the risk of losing bookings in case of unsuccessful delivery, 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. A PULL interval of 1 hour is recommended for low traffic properties. Adjust for high traffic properties or according to your needs.
WebHotelier confirmation numbers are unique.
Your system should never accept a "new" booking with a previously imported confirmation number (id).