Understanding the Hotel Trader Push API Components
1. Metadata Push and Audit APIs (Mandatory)
All clients must implement these APIs to automate the metadata creation and update process
- Metadata Push API (REST API): Sends metadata such as hotel details, rate plans, room types, cancellation policies, and taxes.
- Metadata Audit API(REST API): Audits the metadata received and processed by the client’s system.
2. Receiving Availability, Rates, and Inventory (Mandatory)
Push clients must implement the PUSH XML schema to receive:
- Availability and inventory (OTA_HotelAvailNotifRQ, OTA_HotelAvailNotifRS)
- Rates (OTA_HotelRatePlanNotifRQ)
3. Price Check
Perform price checks using the GraphQL Quote method before making a reservation to ensure accurate rates and availability.
We strongly recommend integrating and using the Price Check API even though it is not mandatory.
4. Pushing Reservations
Send reservations upstream and get confirmation which includes the CRS/PMS confirmation codes.
Integration Path
Quick overview of the integration path:
- REST based Content API: Receive and keep your metadata updated in real-time.
- SOAP XML Schema: Receive ARI from Hotel Trader through a push integration
- OTA_HotelAvailNotifRQ: Receive availability objects.
- OTA_HotelRatePlanNotifRQ: Receive rates and inventory.
- GraphQL Price Check API (Quote - Hybrid): Checks the latest price before sending reservations.
- GraphQL Reservations APIs:
- Sends reservation requests.
- Modify and cancel reservations.
- Retrieves existing reservations.
Existing clients can continue to use the OTA_HotelResNotifRQ and OTA_HotelReadResRQ objects to send and retrieve reservations using the XML based schema.
Processing ARI and Metadata Messages
Clients integrating with Hotel Trader through the Push Model are required to implement both the Push API (for ARI messages) and the Content API (for metadata messages). Your systems must be optimized for quick and reliable responses to avoid timeouts, processing delays, or synchronization issues.
Response Time Expectations
- Timeout Policy: Hotel Trader will timeout any push message (ARI or metadata) if no response is received within 15 seconds.
- Recommended Response Time: Your endpoint is expected to respond within 2 seconds.
- Background Processing: If processing takes longer than 2 seconds:
- Validate the mandatory fields in the request.
- Respond with a Success status immediately to acknowledge receipt.
- Continue background processing without delaying the response.
Getting Your Servers Ready
High Data Volumes and Concurrency Considerations
Hotel Trader’s systems push large amounts of data, particularly when a new hotel is enabled or disabled. Your system must be prepared for:
- ARI Messages:
- One ARI message may contain 700+ days of availability, rates, and inventory.
- Up to 10 concurrent ARI messages may be sent to your server.
- If 10 messages are in progress, an 11th message is queued until a response is received for one of the prior messages.
- Metadata Messages:
- Each hotel launch can involve 100-200 metadata messages, covering properties, rateplans, room types, taxes, and cancellation policies.
- Batches of up to 1,000 properties may be launched at once.
- Metadata transmission for a batch may take 5-10 minutes to complete within Hotel Trader’s system.
Key Considerations for Clients
To ensure smooth integration and avoid bottlenecks, your systems must support:
- Concurrent Processing: Handle simultaneous data transmissions efficiently.
- Scalability: Dynamically scale infrastructure to handle high-volume bursts.
- Efficient Data Pipelines: Optimize data ingestion, validation, and storage processes to prevent processing delays.
- Performance Testing: Rigorously test your production environment to ensure it can handle increasing message loads as more properties are added.
Messaging Format
Hotel Trader follows a customized OTA XML (HTNG2008a) specification for Demand Client integration. Modifications are made to align with upstream integrations with various Central Reservation Systems (CRSs). Developers integrating with Hotel Trader must be familiar with HTNG2008a specifications and end-to-end hotel PUSH ARI and metadata processing.
Transport Protocol Specifications
- HTTPS
- Public IP address to whitelist for ARI messages NAT IP Address:
- 44.214.248.55
- 52.55.205.152
- 107.20.164.116
- Public IP address for reservation messages - HAProxy IP Address [To be provided if required by Client system]
- Protocols enabled
- TLS1.2
- Protocols NOT enabled
- SSLv3
- SSLv2
- TLS1.1
- TLS1.0
- Cipher suites enabled
- TLS_RSA_WITH_AES_128_CBC_SHA (0x002F)
- TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
- TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003C)
- TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003D)
- TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009C)
- TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009D)
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xC013)
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xC014)
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xC027)
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xC028)
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xC02F)
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xC030)
- SNI is disabled
NAT IP Address
Hotel Trader uses the NAT IP address XX.XX.XXX.XXX, which clients must whitelist to allow API requests from Hotel Trader. The IP address will be provided separately.
Client IP Whitelisting
- Clients must provide the IP addresses of their test and production servers.
- Hotel Trader will whitelist these IP addresses to allow API requests from the client’s system.
Authentication Method
Basic Authentication with the same credentials as ARI Push APIs.
Header and Credentials
All messages use the SOAP protocol, which includes a SOAP Security header for authentication and a SOAP body containing the OTA message. During integration, the Hotel Trader Sales team will provide you with security credentials for the SOAP Header.
Sample
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soap:Header>
<wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" soap:mustUnderstand="1">
<wsse:UsernameToken>
<wsse:Username>XXXXXX</wsse:Username>
<wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">YYYYYYYYY</wsse:Password>
</wsse:UsernameToken>
</wsse:Security>
</soap:Header>
<soap:Body>
<OTA_HotelAvailNotifRQ xmlns="http://www.opentravel.org/OTA/2003/05" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" MessageContentCode="3" TimeStamp="2017-03-21T11:31:32.5876714Z" Target="Production" Version="1.001" EchoToken="d5ea7f53-e49d-42c2-a517-d79df55df735">
<AvailStatusMessages HotelCode="[HOTEL CODE PROVIDED BY Hotel Trader]">
<AvailStatusMessage BookingLimit="10" BookingLimitMessageType="SetLimit">
<StatusApplicationControl InvTypeCode="[ROOM CODE PROVIDED BY Hotel Trader]" RatePlanCode="[RATE PLAN CODE PROVIDED BY Hotel Trader]" Start="2015-11-15" End="2015-11-15" />
<LengthsOfStay>
<LengthOfStay Time="2" MinMaxMessageType="SetMinLOS"/>
<LengthOfStay Time="5" MinMaxMessageType="SetMaxLOS"/>
</LengthsOfStay>
<RestrictionStatus Status="Open"/>
</AvailStatusMessage>
<AvailStatusMessage BookingLimit="10" BookingLimitMessageType="SetLimit">
<StatusApplicationControl InvTypeCode="[ROOM CODE PROVIDED BY Hotel Trader]" RatePlanCode="[RATE PLAN CODE PROVIDED BY Hotel Trader]" Start="2015-11-15" End="2015-11-15"/>
<RestrictionStatus MinAdvancedBookingOffset="P30D"/>
</AvailStatusMessage>
</AvailStatusMessages>
</OTA_HotelAvailNotifRQ>
</soap:Body>
</soap:Envelope>