Transition Guide Version 3

Question: Why should I update my code to Version 3?

Answer: Version 3 offers a host of improvements for speed, reliability, features, and available platforms:

• Server response is quicker and more reliable thanks to use of Akamai's hosting technology.
• You can now easily develop for mobile platforms by using IP-less signature authentication and support for SOAP requests.
• Version 3 consolidates many request elements into more easily-manageable objects
• Offers new features such as cache tolerance control and the option to request hotel information within the hotel room request.

Lastly, the legacy API is no longer supported and is in the process of being phased out. With the legacy API pending complete removal in the coming months, a timely transition is critical to keep your application working as expected. Get started now to take advantage of the speed and power of Version 3 as soon as possible!

Question: If I'm updating from Version 200631, can I transition to Version 3 requests one step at a time until I work my way through the complete booking process?

Answer: Absolutely! All requests are stateless, so you can work your way through the booking path one step at a time. This will afford you the benefit of using Version 3 immediately.  Simply populate Version 3 elements with the corresponding value from Version 200631 response items. For example, Version 3 rateKey is populated with Version 200631 hrnQuoteKey, Version 3 chargeableRate is populated with Version 200631 nativeRoomRate. To compare requests/results between the two versions, refer to the Step By Step outlines for each step as you work your way through the booking process. This will assist in "mapping" any element name changes between the two versions.

Question: Why do I need to register to gain access to your APIs?

Answer: EAN has selected Mashery to power the Developer Hub and make our APIs publicly available to interested developers. Mashery is providing API key and issue management for all EAN APIs. The registration process gives you test access, which you can use during the development of your application or site. Registering is the first step in your transition to Version 3.

Question: Does having an API key mean I can make live bookings through your APIs?

Answer: No. When you first receive your key, it is authorized to make test (static) bookings only, and it will be restricted to a limit of 5 queries per second or 500 queries per hour. Any bookings made at this test access level will automatically be void.

In order to make live bookings, submit an application for your site to Go Live. Read about our Go Live Process for more information.

Question: Does Version 3 use GET or POST requests?

Answer: All requests use GET, except for the reservation request, which must be sent as POST. In addition, the hotel list request may also use POST when sending a long list of hotel IDs which will allow for the extended URL length.

See our service resources page for a complete reference for all Version 3 requests.

Question: What is the API request URL?

Answer: All Version 3 API requests should be sent to http://api.ean.com. All booking requests must be sent to https://book.api.ean.com. Note that all booking requests must be sent securely.

The new API URL endpoints are backed by Akamai technology to deliver incredibly fast cached responses and help eliminate load-based errors. The legacy axml.travelnow.com endpoint does not support any of these advantages, and is being phased out along with the legacy API.

Question: What CID do I use during testing and development? When do I use my own CID?

Answer: Use CID 55505 for all requests during your development, including static test bookings. Your own unique CID will only be granted live access after a successful site review.

Question: What is the customerSessionId? How do I use it?

Answer: The customerSessionId is a unique value returned by the API after an initial search request. If you code your application to continue to pick up and pass back the customerSessionId through the booking path, you can mark and log each individual user's actions for any given session.

If you have a separate session tracking system that generates its own IDs, you can pass in those values as the customerSessionId and the API will retain that value as long as your application does for any given request and response.

Question: Which API key do I use? When do I need to send it? Is it different for testing? How does it relate to my CID?

Answer: You must use the API key generated for you when you register on the Developer Hub. Your Legacy API key(s) will not work for Version 3 requests.

Your API key must be sent in every API request along with your CID in order to authenticate your request, including test requests.

Simply send the test CID of 55505 instead of your own along with your API key for test requests. There is no test API key you need to use in place of your own.

Your API key simply grants you the basic ability to interact with the API. It is your CID that is directly connected to your sales and commissions. From your initial registration, your API key is already enabled, but we do not grant any live salable access to your CID until you pass a site review. This is why you will use the test CID of 55505 and your own API key during development.

• How do I decide whether to use a shared secret or IP-based authentication?
• What are the requirements to Go Live?
• How do I implement my key?