Innovating the web using kayak

When talking about Web 2.0 applications on the internet, there are so many that you could never imagine coming up with something new that users think is actually valuable to their user experience. Therefore when commodity components are in abundance, value can be created by simply snapping together two or more existing services in novel or effective way. O’Reilly refers to this value as ‘Innovation by Assembly’ (2007). Some of the best Web 2.0 applications use this technique.

Prior to Web 2.0, the web application directly integrated with a partner business application. Whereas a web application now integrates with a web service and any partner businesses plug straight into the web service also. These web platforms allow external developers to build on another company’s data and services in the form of an application programming interface (API) (Lardinois, 2009).

Companies offer open APIs as a means for growing their business, to encourage developer innovation, monetize data, connect with partners or get to mobile and connected devices (O’Dell, 2011). It could be said that APIs foster third party innovation (Watson, 2012). It allows others the opportunity to beat the competition by getting better at integrating services provided by major players. Smaller companies leverage the power of the web platform, making it a seamless, almost invisible part of their infrastructure (O’Reilly, 2007). To give you some idea of how big innovation in assembly is Twitter has around 13 billion requests per day (Bennett, 2011).

Social media APIs are responsible for adding a new layer of functionality to popular services and have spawned a new era of innovation, what some call ‘developer ecosystems’ that are built on top of more popular services such as Twitter or Facebook (Parr, 2009).


This video –  Google Maps API and Kayak explains how Kayak uses Google Maps API. As an example, customers can locate accommodation on maps to ensure they book hotels where they want to stay.

Kayak is one of the top travel meta-search engines on the web. They did have a free API which allowed programmers access with a developer key to get flight and hotel information. Unfortunately the Kayak Search API is no longer supported because of costly misuse of the search API. See their message here. 

Segaran demonstrates in his book how to perform real flight searches using the Kayak API. This API had a nice XML API that could be used within a python program (2007, p. 101).

Kayak’s website and mobile apps enable easy comparison of hundreds of travel sites at once, in one comprehensive, fast and intuitive display. Kayak also offers a choice of where to book, it will send the customers right to a booking pages to finish purchases including airline, hotel, car rental and online travel agency sites (Kayak, 2012). All these tools are integrated using APIs and is very innovative. Most other travel sites do not offer all these options on one platform.

Comparison to other apps

TripIt is a site where all travel information for a person is stored in the one place.

  • Create an itinerary by forwarding confirmation emails to
  • There is a mobile app to access travel information anywhere.
  • Get alerts for flight changes, cancellations, fare refunds, and more.

Users place all their travel information into one database – flight times, hotel details, costs even their entire itinerary.

So immediately, I think of the amount of information available for other applications to use. TripIt actually gives developers ideas about what they think would be good applications:

  • Populating an iPhone flight-tracking application with a TripIt traveler’s upcoming flights
  • Building a web-based expense report using TripIt itinerary data
  • Sending travel data to Facebook travel applications
  • Providing an “add to TripIt” link on a travel booking confirmation page
  • TripIt flight arrival details to schedule airport pick-ups.

TripIt provides a list of applications that have already been designed by others here

Legal and Ethical implications

The terms of use page for TripIt is very long. Essential elements are usual ones – privacy and confidentiality but there is an interesting one:

TripIt may change, suspend, or discontinue any aspect of the TripIt APIs at any time, including the availability of any TripIt API.

This says the TripIt could basically stop the API feeds at any time and the 3rd party application would fall over and TripIt could not be held responsible.

Does a programmer consider this when they start pouring their heart and soul into designing an application that uses another platforms data?

Future Directions

I guess for this website – they have already listed what they think is the future directions of the platform. They want programmers to design a list of applications that they have provided….. Let’s hope programmers think of bigger and better things then they have ever considered.

Unfortunately travel APIs have a bad reputation of not hanging around long – Kayak is a very good example……. So lets hope that TripIt will hang around. What if one day, you can forward your airline confirmation to TripIt and you are automatically checked in!

Can you think of any other applications that could use TripIt’s data?


Bennett, S. (2011). Twitter: 900,000 Apps, 600,000 Developers And 13 Billion API Requests Per Day [STATS].   Retrieved March 29th, 2012, from

Kayak. (2012). About Us.   Retrieved March 29th, 2012, from

Lardinois, F. (2009, March 24th). Top 10 Web Platforms of 2009.

O’Dell, J. (2011, March 29th). Should Your Company Offer an API?

O’Reilly, T. (2007). What is Web 2.0: Design patterns and business models for the next generation of software.

Parr, B. (2009, March 24th). An Inside Look at 4 Developer Ecosystems.

Segaran, T. (2007). Programming collective intelligence: building smart web 2.0 applications: O’Reilly Media.

Watson, J. (2012). Innovation in Assembly. On Web 2.0 Applications. Brisbane: Queensland University of Technology.


10 thoughts on “Innovating the web using kayak

    • No Kayak stopped their API a couple of years. I did not realise this until I did some thorough research into and could not find any information about it……I think TripIt API is an even better replacement as a travel API.

      • Interesting you ask? I did not know about TripIt before investigating their API. But as an avid traveller I think the services that Trip It are great for ensuring all tickets and itinerarys are in the one spot. The important thing for TripIt is to get as many people adding their data so the API will actually provide good information for the next person….

  1. I’d like to see a mashup of tripit and urbanspoon. Think ‘Hey I’m stopping by in this city for four hours – bing! you should try this Japanese restaurant only 20mins from the airport’. That would be cool 🙂

    Never heard of kayak before though… website’s not too flashy.

    • You have a great mashup idea Reece. The assembly of these mashups is amazing and so simply really. If a programmer can access the data then anything is possible. I guess it is so innovative. Hence O’Reilly’s quote of ‘Innovation in Assembly’! So can you program this Urbanspoon tripit mashup, Reece? You might be a millionaire tommorrow.

  2. Nice post! I never heard about Kayak before. Not sure why it discontinued because it was a good and innovative product. But I heard that Google will sell Augmented reality glasses. This glasses is awesome! In general, it’s like having layer information in your glasses. For example, if you are in a shop and looking at a coffee machine with this glasses, the glasses will provide you a data mashup of pricing information from several stores. You can go to for more information about augmented reality 🙂

    • Thanks for the info on Google. They are always one step of everyone else aren’t they? I guess that is why they are worth so much! It is hard to imagine our lives in 10 years time – what we will think is normal everyday stuff – looking at pricing of a coffee machine without having to physically walk into each store!

  3. Nice reading the article. It was a bit surprise to see terms of use of API provider that they will not be responsible for whatsoever reason if they discontinue/suspend/shut down their API for developers.

    I guess, If I were API provider then I might have written something like that so that developers risk using my API and allow me to outgrow by their product.

    Seems like free service always comes with sort of risk 🙂

    I will appreciate for your views on my article about tricks of Innovation in Assembly.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s