Version 1.3
The Hooroo API is an interface for Channel Managers to send hotel property room information, known generally as Availability, Rates and Inventory (ARI) to Hooroo. The Hooroo API is a subset taken from the relevant parts of the Open Travel (OTA) specification 2011B. Some messages do contain minor differences to the specification. These are noted in the documentation for each message.
The Hooroo Extranet API is an XML over HTTPS interface. Messages are defined in XML formats, based on the 2011B Open Travel Alliance OpenTravel Specification for hotels. Some messages contain minor differences to the OpenTravel Specification. All messages should start with a valid xml header and be encoded in UTF-8.
The content type of POST requests to the Hooroo API should be set to 'application/xml'.
Note: The API is only available as XML over HTTPS interface. Please do not attempt to make calls to the API via SOAP.
All messages (inbound and outbound) use HTTP Basic Authentication. An authentication failure will result in a response with a 401 Unauthorized HTTP status code. All requests must use SSL/TLS.
When you are ready to go live, Hooroo will provide credentials for the Production environment.
You can only make requests against properties where the hotelier has previously selected you as their channel manager in the Hooroo Property Portal. Any attempted unauthorized access to your properties is logged and will result in a 403 Forbidden status message.
Inbound requests will return an HTTP status code of 200 OK or 202 ACCEPTED when a message is successfully received and can be processed. The response body may contain details of any errors that may occur during the processing. This can result in a 'mixed' response body (i.e with success and error elements) for a request that returns a 200 or 202 status code (refer to Error message format below).
Inbound requests that cannot be processed will result in either a 400 Bad Request (client error) or 500 Internal Server Error (server error) status code.
If any errors occur during the processing of inbound messages, errors will be returned in the response. The response should always be inspected for the <errors> element, which will contain one or more <error> elements.
The format of each error element is as follows:
key||error1|error2|...|errorN
The key is either a general_error, applying to the entire request, or a string made up of the identifying attributes of the element that has errored.
For example, in an Rate Plans notification message, a Rate element would be identified by the key:
Start: 2006-06-28, End: 2006-06-28
The errors are a plain text description of the problem. Some examples of error messages:
<Error>general_error||Requested property does not match property in request body.</Error>
<Error>HotelCode: 7, InvTypeCode: R02, Start: 2011-09-24, End: 2011-09-29||Invtypecode not found</Error>
<Error>HotelCode: 7, InvTypeCode: R02, Start: 2011-19-24, End: 2011-09-29||Invtypecode not found|Start date needs to be a valid date, e.g 2011-09-01</Error>
<Error>general_error||Too many properties in request. Only a single property is allowed.</Error>