Each time a person uses a transport service they can create a trail of data behind them. This trail is particularly rich when technology is used as either the medium for purchasing (e.g. a credit card or online payment service) or when used for the actual transportation (e.g. a ride sharing app, a smartcard, etc.).
But what happens to this data when reservations or tickets for different modes of transport are purchased on multiple websites, apps and kiosks? And what is the impact when journeys are taken using different combinations of buses, trains, subway, car share, etc.?
This data ends up scattered around a number of databases or information stores run by each transport provider. Which then creates an issue:
The customer doesn’t have a joined-up picture of their own purchases/tickets and journeys made.
The Open Transport API has been created to provide a standard for the interoperability of any transit service / transport provider account. It allows this fragmented data to still be stored in different systems, whilst also providing an aggregated view of this data in the account of the customer’s choice.
Following recent contribution from transport subject-matter-experts (SMEs) and technical specialists, we have now update the draft API Specification.
This draft is currently at version 0.2
Note: This API Specification is not yet at a peer review stage. If you would like to be involved please contact us
We believe that the use of an Open transport API will facilitate the standardisation of digital account integration for transport providers. Which will in-turn help to bring true interoperability of data, such as ticketing/purchase and journey information.
But the private sector transport cannot implement this initiative alone. It requires universal support to make the change towards a workable MaaS (Mobility-as-a-Service) multi-modal multi-operator model for all customers. Thus helping to shift people towards mass transit that will reduce emissions and deliver health benefits for society.
More active means of travel are only going to become more prevalent across entire transport networks in the future. With journeys being made via car-sharing, sustainable transportation and potentially other more innovative schemes (e.g. powered scooters) . But this requires a collective embracing of an Open Standards for account interoperability across the combined private and public sectors.
We therefore think it is an obvious role of any Transport Authority to widely encourage the use of a open standards for transport accounts. With the eventual aim of delivering true data interoperability and reducing barriers to customer adoption.
Or put a different way… every Transport Authority needs to ensure that they do not stifle development in newer integration technologies and provide direction & help in making sure that consistent inter operable transport standards are adopted and maintained.
Mobility-As-A-Service (“MaaS”) is the concept that users of transport or transit services migrate away from personally owned means of transportation and adopt an on-demand & pay-per-use service instead. This shift in behaviour (and potentially billing) means a user can then choose their preferred trip based on: cost, time, environmental factors, convenience or a combination of these.
But how does the creation of an Open API for transport account interoperability forward the aims of Mobility-As-A-Service?
- A clearer view of online transport accounts
The aggregation of accounts via single interoperable standard API would give consumers the ability to quickly, simply and efficiently consolidate all their accounts into one place. E.g. to use one chosen online travel account for viewing information about all other modes (e.g. bus tickets, rail carnets, etc.).
There is even the potential opportunity to allow new services into the market, in the same way that Money Dashboard (https://www.moneydashboard.com) uses Open Banking technology to give consumers a ‘unified view of their finances’ and is called an Account Information Service Provider (AISP).
- Removing barriers to MaaS adoption
It is anticipated that by creating an easier way for consumers of travel services to access multiple accounts online, that they are more likely adopt it and use it. Therefore by removing the need to sign-up or remember new account details for every different MaaS provider, a key barrier to the use of multiple mobility service is removed.
- Reducing the cost of innovation
Providing anything from scratch is usually quite hard, whereas copying or adopting what already exists is easier. IT Departments or their suppliers don’t have to spend time and money coming up with a new way to integrate with another travel account.
Plus the benefit of an Open Standard is that, should it need changing or enhancing, this can be fed back into the standard too.
An Open Transport account standard can potentially be used for many different purposes (some of which we may not even know about yet).
Some examples of account interoperability could include:
- Enable a customer to view the details of a joint rail & subway or a combined bus & ferry ticket
- Presentation of all transport permutations taken as part of a MaaS (Mobility-as-a-service) system, especially in a fragmented or deregulated transport provider network
- Allow new services to be created that provides a single “transport dashboard” view of all participating accounts
- Reporting back to the customer or operator the environmental / green impact of their total journeys
- As the basis of a multi-modal gamification service (e.g. in the same way that smart energy meters now encourage customers to use fuels more efficiently & cheaply)
- Collation of all unpaid journeys or tickets in one central place and then used as the basis if a multi-modal Account Based Travel (ABT) or ePurse proposition
This standard can also either be adapted into existing systems or used as the basis for new ones.
In this site we have explained the concept behind our Open Transport API and it helps different accounts integrate with each other via a common a API standard.
To communicate this better, we thought we would also create this diagram to help describe how things will work. As you can see below, different online accounts are able to connect via Open Transport APIs and view each other’s information… without exposing their own back-end technologies & systems.
Hayden’s recent article on LinkedIn explains that some USA public transit operators are using loyalty schemes to try to shift customers to their less congested (and often more environmentally friendly) modes of transportation.
But how could such a scheme work in those areas where transportation services are fragmented, deregulated, privatised or just provided by different systems and technologies?
The truth is, that unless there is a common way for each different transport operator to integrate with the accounts of other operators (and at the most basic level of functionality to view some journey and ticketing data)… then a single consolidated view of travel will not be possible.
So how do we create the ability for all accounts to be inter-operable? By the use of open and usable API standards that both:
- Private sector suppliers can adopt over time (although the faster they do this, the more competitive they make their products)
- Public sector organisations & operators embrace and mandate in all future transport tenders or franchises.
We are pleased to announce that we have created and published an initial draft Open Transport Application Programming Interface (API).
This can be found on SwaggerHub here:
The aim with any open standard is to:
- Give it away, so that it can be adopted as widely as possible
- Encourage feedback and suggestions
- Allow it to develop in the same open manner
What problem are we trying to solve?
Well… Providing a self-service digital/online presence is a necessary requirement for any transport solution. Regular customers and visiting tourists alike expect this, plus the amount of understanding & insight that can be gained from a single source of online customer data has multiple benefits for operators and authorities.
However each individual operator/provider: has already implemented, has plans to implement or would like to implement one an online account.
But each online account will be:
- Limited to a single operator or provider
- Different in the type and structure of the data they contain (often predicated by the software system/vendor/developer used)
- Developed just for the single purpose / use cases intended (and not to be extensible or subsequently integrated )
- Implemented with differing terms & conditions around data usage and governance at different times