General Design and Best Practice Considerations

ALLOTMENTS/ALLOCATIONS

Allocations or allotments refer to guaranteed space given for any service item. An allocation is a set number of rooms or places or seats, which are held by the supplier for GTA’s use. The supplier agrees to ‘block’ this space on our behalf so that GTA can use these ‘blocked’ rooms, places or seats to confirm them to our clients immediately without the need of consulting the supplier for every request. As a result of having these allocations it obviously allows us to confirm bookings much quicker than if we have to contact the supplier. If the item prices searches are being sent to us with the <ImmediateConfirmationOnly/> element we will only ever return items that available immediately from our allotments.

 These days our suppliers make the most of the technology available to manage their inventory and prices as well as the availability of rooms can change at any time of the day. It is therefore possible that a specific item and price is no longer available at booking stage even though it was returned by us moments earlier with the price search response. To minimise any issues resulting from this volatility of inventory we suggest that before sending an <AddBookingRequest> an additional price search is performed for the required item to re-check availability and price accuracy. For further information specifically for hotel bookings please also refer to the following information available in the Final Price and Availability Check document.

ALTERNATIVE HOTELS

If we are not able to confirm your requested hotel and if you have sent the <AlternativesAllowed> element as ‘true’, we will, whenever possible, confirm an alternative hotel, taking into consideration the category, location and price of your originally requested property. We will always try your requested property first and will only confirm an alternative if the originally requested property is not available.

 It is your responsibility to cancel such alternatives if you do not approve them. Failure to cancel an alternative that is not acceptable will result in non-arrival charges.

 We will not confirm an alternative hotel if you have sent the <AlternativesAllowed> element as ‘false’.

If you have a confirmed booking and send us a request to amend either the rooms, check-in date or number of nights, we will always either confirm the amendment in the same hotel or reject the amendment and re-confirm the original request. We will never confirm an alternative hotel for an amendment of an already confirmed booking even if the <AlternativesAllowed> element is flagged to ‘true’.

COMPRESSION

GTA does support compression and using it would be beneficial for you for the following reasons:

  • It will increase the speed with which we send responses back to you
  • It will reduce utilisation of your communication line
  • Through the testing we have performed we have seen a decrease of between 16% and 68% of the network time (internet)

We do support both, deflate and gzip. In order to receive a compressed response you will need to add either of the following to the HTTP-Header of your XML request:

  •  ‘Accept-Encoding: gzip’
  •  ‘Accept-Encoding: deflate’

Following is an example of HTTP-Header with compression:

POST /gtaapi/RequestListenerServlet HTTP/1.1
Content-Type: text/xml; charset=utf-8 
Accept-Encoding: gzip
Content-Length: 717
Expect: 100-continue
Connection: Keep-Alive
Host: interface.demo.gta-travel.com

Please note that:

  • We are not compressing responses that are smaller than 1024 bytes
  • You will need to check the content length when reading the HTTP-Header

When compression is enabled, the ‘Compression Buffer Size’ setting specifies the maximum number of compressed bytes that the GTA BIG-IP LTM buffers before deciding whether or not to preserve a Keep-Alive connection and rewrite the Content-Length header. For example, using our value of 153KB, the BIG-IP LTM buffers up to 153KB of compressed data before deciding whether or not to preserve the connection and rewrite the Content-Length header. The BIG-IP LTM's decision to rewrite the Content-Length header depends on whether response chunking is enabled (using the Response Chunking profile setting). Anything smaller than this buffer, the BIG-IP LTM will insert a “Content-Length” header to indicate the size of the response.

DEPARTURE DATE 

The GTA definition of a departure date is the date when your client is departing from your country; usually the same as the first check-in or tour date of a booking.

The departure date cannot be later than the check-in or tour date of any of your booking items or earlier than 180 days before the earliest check-in or tour date of any of your booking items. If you modify the check-in or tour date to an earlier date then you need to ensure you are also modifying the departure date to an earlier date BEFORE you modify the arrival date. If you modify the arrival date to a later date then you need to ensure you are also modifying the departure date to the same date as the new arrival date AFTER you modify the check-in or tour date. The same applies if you would like to add another item to an existing booking. If the new item has an check-in or tour date that lies before the departure date of the existing booking you first need to send us a <ModifyBookingRequest> adjusting the departure date to the earlier date and then send the <AddBookingItemRequest>.

DURATION

The maximum number of nights you can request for hotel and apartment prices searches and bookings is 90.

FAILED BOOKING REQUESTS 

If you have any failed booking requests for which you did not receive a response at all or for which you received ANY kind of error, you MUST send a cancellation request if you no longer require the booking. Occasionally it is possible that we processed and confirmed your request and you were unable to receive the response and would be liable for payment.

In order to cancel a booking for which you have received no response via the XML API it is not necessary to use the GTA API reference number (which you would not have received in these cases anyway). It is possible and recommended to cancel all bookings using the unique <BookingReference> you used with your <AddBookingRequest>.

 

 

 

 

 

 

 

 

 

 

 

Docs Navigation