Travel APIs

Businesses are moving beyond traditional industry silos and coalescing into networked ecosystems, creating new opportunities for innovation alongside new challenges for many enterprises. Ecosystems typically bring together multiple players of different types and sizes in order to create, scale, and serve markets in ways that are beyond the capacity of any single organization—or even any traditional industry. Their diversity—and their collective ability to learn, adapt, and, crucially, innovate together—are key determinants of their longer-term success. In Eutravel, apart for the travel end users (travellers and businesses that buy travel services) several other key ecosystem stakeholders are considered (Table 1).


Transport Infrastructure

Providers

Transport Service Providers

 

Travel Service Providers

Authorities

Rail Infrastructure Providers/ Managers

Rail Operators

Global Distribution System Service Providers (GDSs)

Mobility Management Authorities

Airport Operators

Air Carriers, Airline Operator

Travel Agents (Retailers),

Travel Management Companies (TMCs)

PT Administration Authorities

Fleet Owners,

Port/Terminal Operators

Ferry Operators

Online Travel Agents (OTAs) (Retailers)

Environmental Authorities

Infrastructure Maintenance Service Providers

Urban/Public Transport Operators (PT)

Car Rental Service Providers

Cross Border Managing Authorities

Toll Operators

Coach Operators

Hotels/ Hospitality Providers

Customs

ITS Solution Providers

Ticket Vendors - Retailers (third parties, apart from operators)

Travel Insurance Service Providers

 


Table 1: EuTravel Ecosystem Participants


Ecosystems formulation are facilitated by the growth of APIs. With the proliferation of Application Programming interfaces (APIs) available both privately and publicly, it becomes very difficult to monitor the latest developments in this area. This is partially alleviated by recently established public registries of APIs where their developers/owners are encouraged to register information about them. 
The API registry used in this research was the Programmable Web [1] that claims to be the world’s largest repository (registry) for APIs, containing in excess of 14,000 API entries at the time of writing this report. To retrieve travel related APIs the category ‘travel’ was used to retrieve relevant APIs from the Programmable Web repository. This approach however is not guaranteed to return the whole list of travel related APIs, nor only APIs that are relevant to travel, as some travel APIs could possibly have been classified incorrectly. The number of results however, (in excess of 300) indicates that (a) the Programmable Web is a useful source of API information and (b) the proliferation of travel related APIs. Also, although the search opted to exclude deprecated APIs, there is no absolute certainty that the APIs found are still actively used/supported by users and their developers. 

The next step in the process involved the filtering out of APIs that were deemed to have a narrow geographical coverage, i.e. covering travel information within a city or region- but not country or continent level, as EuTravel has a pan-European scope. 

The number of travel APIs in the filtered list obtained in this manner was still too high and therefore not useful to provide patterns, trends and insides into the current travel related API market. As the purpose of EuTravel is to develop an ‘API of APIs’ it was considered important to define the breadth of coverage and scope of such API. This would require some classification of existing travel APIs however. As such classification did not currently exist, we decided to propose one that is empirically derived by analysing the descriptions of the discovered APIs and identifying common themes that appear across them. Thus, this is not a strict classification as APIs may straddle several themes and some APIs may appear to not belong to any of the proposed themes. Instead this classification was proposed in an attempt to scope the planned ‘API of APIs’. 
The classification proposes the following five themes:
      APIs oriented towards developers that want to integrated/aggregate existing travel services (e.g. to create portals. Mashups, for travel aggregators). These also cover multiple travel modes (sea, land, air) and facilities (e.g. car and hotel hire). These APIs have transactional capability (e.g. create bookings). 
      APIs oriented towards one type of service/travel mode (e.g. air travel) and/or one provider (e.g. one particular airline only). These APIs also may have transactional capability. 
      APIs that provide travel related but static information (e.g. about locations such as places to visit or airports) but they do not (normally) support itinerary planning as timetabling and dynamic travel information is not included 
      APIs that provide timetable-like information such as bus or flight arrival information, flight tracking, for single or multi-mode but (normally) no booking functionality. 
      APIs that allow the sharing of information or resources between travellers, such as recommendations about visiting places, travel routes and trails etc. 

[1] View at http://www.programmableweb.com

<