kSIST-TP FprCEN/TR 18362:2026

Guidelines for building multimodal travel purchase APIs based on Transmodel

The scope of the proposed work item will be:
-   The context of the work done within CoRoM,
-   The data information flow and steps required for purchasing any multimodal travel (including basic after sale), from the perspective of travellers,
-   How to use Transmodel (EN 12896) to represent them (only Transmodel based concepts and data structure should be taken into account),
-   A study of a range of existing APIs and their functionalities, which include OSDM, TOMP-API, BoB, Entur API, FerryGateway, (EU) 454/2011 (TAP TSI) etc.
-   The implication of such study for Transmodel (EN 12896)
-   The implication of such study on the purchase APIs taking into account the Transmodel approach.
The last part of this proposed work item will inform the revision of Transmodel Parts 5 and 6 (EN 12896-5 and EN 12896-6) and NeTEx Part 3 (TS 16614-3).
This TR covers the following functional scope:
-   Provision of a catalogue / fares consultation
-   Request for specific fare offers (including criteria)
-   Selection of a formal offer by the customer (pre-purchase)
-   Initiate the purchase
        o   commitment to buy
        o   reservation
        o   evidence of the purchase
-   Manage after purchase (basic after-sale actions)
-   All interactions can be related to persistent identity
The following items are not in scope:
-   creation and distribution of the travel document
-   travel planning
-   payment as interface with bank SI
-   access right validation
-   access right control

Richtlinien zum Aufbau multimodaler Reisebezahl-APIs basierend auf Transmodel

Smernice za razvoj programskih vmesnikov API za multimodalni potniški promet na podlagi Transmodela

Obseg predlaganega delovnega elementa bo zajemal:
- Kontekst dela, opravljenega znotraj CoRoM,
- Tok informacij in korake, potrebne za nakup katerega koli multimodalnega potovanja (vključno z osnovnimi poprodajnimi storitvami), z vidika potnikov,
- Kako uporabiti Transmodel (EN 12896) za njihovo predstavitev (upoštevati je treba le koncepte in strukturo podatkov, ki temeljijo na Transmodel),
- Študijo obstoječih API-jev (vmesnikov za programiranje aplikacij) in njihovih funkcionalnosti, ki vključujejo OSDM, TOMP-API, BoB, Entur API, FerryGateway, (EU) 454/2011 (TAP TSI) itd.
- Posledice takšne študije za Transmodel (EN 12896)
- Posledice takšne študije na API-je za nakup ob upoštevanju pristopa Transmodel.
Zadnji del tega predlaganega delovnega elementa bo obveščal o reviziji delov Transmodel 5 in 6 (EN 12896-5 in EN 12896-6) ter NeTEx dela 3 (TS 16614-3).
Ta tehnični poročilo (TR) pokriva naslednji funkcionalni obseg:
- Zagotavljanje kataloga / posvetovanje o tarifah
- Zahteva za posebne tarifne ponudbe (vključno z merili)
- Izbor formalne ponudbe s strani stranke (pred nakupom)
- Začetek nakupa
  o zaveza k nakupu
  o rezervacija
  o dokazilo o nakupu
- Upravljanje po nakupu (osnovna poprodajna dejanja)
- Vse interakcije so lahko povezane s trajno identiteto
Naslednji elementi niso v obsegu:
- ustvarjanje in distribucija potovalnega dokumenta
- načrtovanje potovanja
- plačilo kot vmesnik z bančnim SI
- validacija pravic dostopa
- nadzor pravic dostopa

General Information

• Status: Not Published
• Public Enquiry End Date: 24-Jun-2026
• ICS: 35.240.60 - IT applications in transport
• Technical Committee: ITC - Information technology
• Current Stage: 5520 - Unique Acceptance Procedure (UAP) (Adopted Project)
• Start Date: 15-Apr-2026
• Due Date: 02-Sep-2026
• Ref Project: FprCEN/TR 18362 - Guidelines for building multimodal travel purchase APIs based on Transmodel

Standards Content (Sample)

SLOVENSKI STANDARD
01-junij-2026
Smernice za razvoj programskih vmesnikov API za multimodalni potniški promet
na podlagi Transmodela
Guidelines for building multimodal travel purchase APIs based on Transmodel
Richtlinien zum Aufbau multimodaler Reisebezahl-APIs basierend auf Transmodel
Ta slovenski standard je istoveten z: FprCEN/TR 18362
ICS:
35.240.60 Uporabniške rešitve IT v IT applications in transport
prometu
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

FINAL DRAFT
TECHNICAL REPORT
RAPPORT TECHNIQUE
TECHNISCHER REPORT
April 2026
ICS
English Version
Guidelines for building multimodal travel purchase APIs
based on Transmodel
Richtlinien zum Aufbau multimodaler Reisebezahl-
APIs basierend auf Transmodel
This draft Technical Report is submitted to CEN members for Vote. It has been drawn up by the Technical Committee CEN/TC
278.
CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway,
Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and
United Kingdom.
Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are
aware and to provide supporting documentation.

Warning : This document is not a Technical Report. It is distributed for review and comments. It is subject to change without
notice and shall not be referred to as a Technical Report.

EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2026 CEN All rights of exploitation in any form and by any means reserved Ref. No. FprCEN/TR 18362:2026 E
worldwide for CEN national Members.

Contents Page
European foreword . 3
Introduction . 4
1 Scope . 6
2 Normative references . 6
3 Terms and definitions . 6
4 Abbreviations . 9
5 Context . 10
5.1 Purchase and reservation as the enabler of cross-European travel . 10
5.2 Laying the foundation for future automated redress handling and independent trip-
repair agencies . 11
5.3 Learning from other industries opening their purchase & reservation systems . 11
5.4 The definition of "booking" or lack thereof . 12
5.5 Methodology. 13
5.6 Exclusions . 15
5.7 Preliminary conclusions . 15
6 Multimodal travel purchase APIs basics, roles and use-cases . 16
6.1 Basics . 16
6.2 Roles . 16
6.3 Additional principles . 27
6.4 Travel Guarantees . 28
6.5 Use-cases . 29
7 Existing Transmodel Elements relevant for a multimodal travel purchase API
specification . 72
7.1 Introduction . 72
7.2 Using Transmodel to model these use cases . 74
7.3 Overview of existing Transmodel Model for trips and fares . 86
7.4 Overview of existing Transmodel queries for Trip Planning and Fare Finding . 104
8 New Transmodel concepts to support Multimodal Travel Purchase/Reservation APIs 108
8.1 Introduction to new Transmodel concepts . 108
8.2 Extensions to the Transmodel Trip Model . 108
8.3 Additional Transmodel multimodal travel purchase API . 123
8.4 Example of multi-supplier travel packages and the travel basket concept . 124
Annex A (informative) BoB API . 129
Annex B (informative) OSDM API . 132
Annex C (informative) TOMP-API. 137
Annex D (informative) Entur API . 143
Annex E (informative) FerryGateway API . 144
Annex F (informative) TAP TSI API . 148

Annex G (informative) Comparison between OSDM & Transmodel elements . 150
Bibliography . 159
European foreword
This document (FprCEN/TR 18362:2026) has been prepared by Technical Committee CEN/TC 278 “ITS
for Public Transport”, the secretariat of which is held by NEN.
This document is currently submitted to the Vote on TR.
This document has been prepared in response to a formal request addressed to CEN by the European
Commission. The request led to the opening of the CoRoM (Coordination & standardisation for Rail &
Mobility) project for which this document is one of the main deliverables.
The CoRoM project aims to provide support to the work to be carried out by the European
Standardisation Organisations (ESOs) for the coordination and standardisation of purchase (including
basic after-sale) interfaces (also called Booking APIs) for multimodal travel (including long-distance rail).
Introduction
For the past decade or so, Mobility-as-a-Service (MaaS) has been developed and implemented in Europe,
mostly in an urban and peri-urban context. The original idea behind such a concept is very simple: allow
travellers to go seamlessly from A to B using one single digital interface and based on their personal
preferences. To roll-out this concept, the travellers’ journey was divided into four main stages: plan,
purchase (with or without a reservation), pay, and travel. These stages are not necessarily linear nor
unique, and most certainly encompass other operational stages for mobility providers.
The planning stage can itself be split into searching through passenger information and planning based
on the desired travel characteristics (e.g., date and time, number of passengers, etc.). This fundamental
activity has been the main focus of the development of Transmodel-based data exchange formats such as
the Network and Timetable Exchange (NeTEx) (CEN/TS 1664 series) for planned information and the
Service Interface for Real time Information (SIRI) (CEN/EN & TS 15531 series) for real-time information.
It also led to the development of the Transmodel-based API specification for trip planning with the Open
API for distributed journey planning (CEN/TS 17118 series).
The purchase stage is one for which further standardisation is needed to support the development of
MaaS solutions. Ideally, it would lead to a common API specification that facilitates the integration of
different types of transport modes into one seamless application, including long-distance travel. It would
then be a standard supporting the European Commission effort to open the distribution of tickets across
Europe, especially the upcoming Multimodal Digital Mobility Services (MDMS) regulation. To support this
standardisation work, a review of existing state-of-the-art existing APIs has been published by another
CEN project team under the name of “Public transport - Distribution APIs for MaaS” (CEN/TR
00278582:2022). The current document takes into consideration the above-mentioned CEN/TR but is
more focused on the inclusion of a deeper analysis, providing guidelines for formulating distribution
standards in better alignment with Transmodel in order to facilitate the purchase for travellers (including
other modes). The goal is to define principles to make existing travel purchase APIs compatible. It is also
based on the latest revision of both Transmodel and NeTEx, which are key to understanding parts of the
present document.
Attention is drawn to the fact that authors of this document have chosen to use the word “purchase”
rather than “booking”. As further explained later in the document, the term “booking” bears several
different meanings in colloquial use, which can generate misunderstanding.
Attention is also drawn to the fact that this document has been written before the European Commission
has released a working draft of the upcoming MDMS regulation. Terms used in the latter might not match
some used in the present document.
This document details:
— The context of the CoRoM project and its methodology,
— The data information flow and steps required for purchasing any multimodal travel (including
basic after-sale processes), from the perspective of travellers,
— The identification of the relevant concepts and data structure from Transmodel (EN 12896
series) to represent the above-mentioned data flow and steps,
— An identification and study of existing APIs that are used in multimodal travel for reservation and
purchasing, which mostly include OSDM, TOMP-API, BoB, Entur API, FerryGateway, and (EU)
454/2011 (TAP TSI),
— The identification of concepts and data structures that should be added to Transmodel to cover
the scope of the studied APIs,
— The guidelines for a multimodal travel purchase API specification based on Transmodel concepts.
The latter two parts of this document will inform the revision of Transmodel Parts 5 and 6 (EN 12896-5
and EN 12896-6) and NeTEx Part 3 (TS 16614-3).

1 Scope
This document covers:
— Provision of a catalogue of fares
— Request for specific fare offers (including specific search criteria),
— Selection of one or several formal offers by the customer (pre-purchase),
— Initiation of the purchase,
— Commitment to buy,
— Reservation of a place on a specific journey,
— Reception of evidence of the purchase,
— Management after purchase (basic after-sale actions),
— All interactions that can be related to a persistent identity.
These functions can be seen as the minimum required for the data flow of reservation from the travellers’
perspective.
Though some of the studied APIs have functions beyond just reservation and involving other parties, the
following activities are not in scope of this document nor the CoRoM project:
— Creation and distribution of the travel document,
— Travel planning,
— Payment interfaces with banking information systems,
— Validation of purchased access rights during travel,
— Control of purchased access rights during travel
2 Normative references
There are no normative references in this document.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminology databases for use in standardisation at the following addresses:
— ISO Online browsing platform: available at https://www.iso.org/obp/
— IEC Electropedia: available at https://www.electropedia.org/
3.1
booking
placing of a reservation to use a specific transport service, but not necessarily entailing a purchase of a
ticket
[SOURCE: EN 12896-5]
3.2
consumption
using up of access rights by a transport customer as a result of travel
[SOURCE: EN 12896-5]
3.3
customer purchase package
purchase of a SALES OFFER PACKAGE by a TRANSPORT CUSTOMER, giving access rights corresponding
to those of one or several FARE PRODUCTs materialised as one or several TRAVEL DOCUMENTs
[SOURCE: EN 12896-5]
3.4
end-to-end trip
TRIP from an origin to a final destination.
3.5
fare
from the customer’s perspective, amount that a customer has to pay for a journey or for acquiring a
specific fare product
[SOURCE: EN 12896-5]
3.6
fare product
immaterial marketable element (access rights, discount rights, etc.), specific to a CHARGING MOMENT
[SOURCE: EN 12896-5]
3.7
individual traveller
individual travelling person
[SOURCE: EN 12896-10]
3.8
inspection
control, i.e., checking of a passenger’s entitlement to consume access rights, involving identification of the
traveller and/or the travel rights
[SOURCE: EN 12896-5]
3.9
parameter assignment
access right parameter assignment: the assignment of a fare parameter (referring to geography, time,
quality or usage) to an element of a fare system (access right, validated access, control mean, etc.)
[SOURCE: EN12896-5]
3.10
price
value of fare or tariff
[SOURCE: EN 12896-5]
3.11
query
function consisting in a request for and a delivery of information
[SOURCE: EN 12896]
3.12
regional trip
TRIP limited to a region
3.13
ticket
unitary travel document allowing a single ride
3.14
transport customer
specific person or organisation involved in a fare process
Note 1 to entry: There can be a FARE CONTRACT between the TRANSPORT CUSTOMER and the OPERATOR or the
AUTHORITY ruling the consumption of services
[SOURCE: EN12896-5]
3.15
travel document
particular physical evidence to be held by a passenger, (ticket, card, etc.) allowing the determination of
the right to travel or to consume joint services
Note 1 to entry: May comprise just a token associated with an online account, or some form of representation of the
access rights
[SOURCE: EN 12896-5]
3.16
travel guarantee
promise that a travel service will be provided to a certain quality level and that a TRAVEL REDRESS will
be offered if the guarantee is not met
3.17
travel package
aggregated information selected from any SALES OFFER PACKAGE (satisfying the trip requirements of
the TRANSPORT CUSTOMER) presented to the TRANSPORT CUSTOMER and enriched by specific
information (i) as to the travel guarantee, (ii) as to the organisation providing the travel guarantee
Note 1 to entry: The new proposed Transmodel TRAVEL PACKAGE element is described in §8.2.2
3.18
travel party
group composed of at least two (02) INDIVIDUAL TRAVELLERs
3.19
travel redress
remedy or compensation that will be offered for failing to meet a TRAVEL GUARANTEE
3.20
trip
part of a TRIP PATTERN describing the movement of a passenger from one PLACE of any sort to another
Note 1 to entry: A TRIP can consist of one or more consecutive LEGs having some common characteristics
[SOURCE: EN 12896-6]
3.21
trip planning
delivery of information related to a request for trip proposals
3.22
validation
verification that an access right is valid, has been or is being consumed, and that this consumption is
allowed, achieved by checking the validity of the passenger’s travel rights and comparing them to the
parameters collected by the previous inspections and/or inspection context
4 Abbreviations
API Application Programming Interface
BoB Biljettdistribution och Biljettvisering
CEN European Committee for Standardisation
CoRoM Coordination & standardisation for Rail & Mobility
DG MOVE Directorate-General for Mobility and Transport
ERA European Union Agency for Railways
EU European Union
GDS Global Distribution System
GIS Geographical Information System
GPS Global Positioning System
HTTP Hypertext Transfer Protocol
IATA International Air Transport Association
IFM Interoperable Fare Management
IFOPT Identification of Fixed Objects in Public Transport
ISO International Standards Organisation
IS Information System
IT Information Technology
MaaS Mobility-as-a-Service
MDMS Multimodal Digital Mobility Services
NeTEx Network and Timetable Exchange
PT Public Transport
OJP Open API for Distributed Journey Planning
OpRa Operating Raw Data and statistics exchange
OSDM Open Sales and Distribution Model
SIRI Service Interface for Real-time Information
TAP TSI Telematics application for passengers
TM Transmodel
TOMP Transport Operators – MaaS Providers
TR Technical Report
UIC International Union of Railways
UML Unified Modelling Language
URI Uniform Resource Identifier
URL Universal Resource Locator
5 Context
5.1 Purchase and reservation as the enabler of cross-European travel
In 2021, President of the European Commission Ursula von der Leyen sent a Letter of Intent to David
Sassoli, the President of the European Parliament, and Prime Minister Janez Janša, as the Presidency of
the Council, in which she detailed the actions the Commission intends to take in the following year by
means of legislation and other initiatives. Amongst them, within the pillar named “A Europe fit for the
digital age”, was the mention of a “legislative proposal on multimodal digital mobility services”, which
refer mostly to route-planners and ticket vendors that help to compare travel options.
The main objective of such a legislative proposal was to serve travellers of the European Union in their
long-distance travels and to ease the integration of public transport and rail services to achieve seamless
multimodal passenger transport, delivering the EU “Green Deal”.
Considering that the provision of EU-wide multimodal travel information to support the development of
route planners is already addressed in the Delegated Regulation (EU) 2017/1926 amended by the
Delegated Regulation (EU) 2024/490 of 29 November 2023, it is logical that the facilitation of purchase,
reservation and payment of mobility services would be covered by the MDMS legislative proposal. In a
sense, it can be considered that “purchase and reservation” is the next piece required to enable cross-
European travel for all.
Also considering that sustainable long-distance travel has a high impact on the Green Deal; and that
MDMS services in the urban and peri-urban areas lead to a stronger integration of several modes of
transport, a better integration of rail services with public transport can be considered as a necessary next
step to enable cross-European travel for all. Additionally, implementations have to comply with GDPR
framework.
The CoRoM project addresses both “purchase & reservation” and a better integration of rail services with
public transport. It builds on pre-existing work as follows:
— The Fares and Timetable, Use-Cases description and mapping for PT and Rail, co-authored by
experts of the CEN and UIC [11],
— CEN/TR 00278582:2022, Public transport – Distribution APIs for MaaS [10].
Finally, considering that the provision of EU-wide multimodal travel information is mandated variously
in NeTEx CEN/TS 16614, SIRI CEN/TS 15531 and Transmodel EN 12896, in none of which there is a
reference exchange protocol for “purchase & reservation”, it seems quite natural that the results of the
CoRoM project would lead to a guidelines for API specification that facilitates multimodal travel purchase
based on Transmodel.
5.2 Laying the foundation for future automated redress handling and independent trip-
repair agencies
In learnings from multimodal travel experience, one of the hurdles encountered when trying to achieve
and promote long-distance travel using combinations of rail services and other public transport is to
solve the problem of broken connections due to delays and cancellations. It is not acceptable that a
potential traveller be stranded half-way.
Today the passenger often has to take action to initiate and get trip repair or obtain other redress for a
failure by the service provider. Instead, there should be an automated redress process, and the
responsibility of initiating trip repair should be moved from the traveller to the carrier.
The redress process should be such that travellers should not have to delve into a complicated legal
process to be reimbursed when their passenger rights are violated.
Instead, it would be better if the traveller could, at least as a second option after the carrier has failed to
provide a solution, contact an EU-backed 24/7 reachable trip-repair / redress agency that is not linked
to the carrier. The agency should judge the situation and provide the necessary trip-repair or redress
without any charge to the traveller. The cost of such redresses could intermittently be covered by funds
based on bank guarantees from the carriers and finally be settled in processes with the carrier without
involving the traveller directly.
Such a handling should be based on real-time information as to the disruption (such as a cancellation or
severe delay) and an electronic ticket that describes all necessary details such as who is travelling (i.e., a
passenger or a group of passengers, their luggage and their passenger vehicles), comfort class, rebooking
flexibility, accommodation and ancillary products, as well as travel guarantees and travel redress
conditions. The API should thus support the exchange of all information needed to support an automated
handling of travel redress, including any identifiers needed to link purchased tickets to real-time
information from the carriers.
5.3 Learning from other industries opening their purchase & reservation systems
The airline industry and air travel, under the umbrella of International Air Transport Association (IATA),
is currently going through a major transformation. IATA recognised that today´s customers’ expectations
are shaped by the digital experience they have of interacting with modern technology companies in other
sectors and that modernisation is necessary.
Their goal was to develop a framework that would support providing the customer with a
straightforward shopping cart experience, having a wide set of choices, towards a single ticket with
seamless transfer and disruption protection also when the customer travels on multiple airlines.
A new framework for partnerships based on Offers and Orders has thus been developed. From a business
perspective, it relies on a Retailer-Supplier model; similarly to the retailing industry, partners engage in
a direct, bilateral relationship
The basis is to use direct API workflows between Retailers and Suppliers, as opposed to yesterday’s
complex, legacy flows using legacy technology (e.g., EDIFACT) and involving multiple third-party systems.
The idea is to provide the customer (air) transportation products and related services across Retailer and
one or multiple Suppliers based on the following workflow:
a) A Retailer requests offers from Suppliers
b) Suppliers provide priced offers to the Retailer
c) The Retailer, incorporating Suppliers’ content, provides priced offers to the customer.
Accordingly, the Retailer is responsible for both the Customer and Supplier relationships, and all partners
gain control of their offer. IATA believes that once implemented at scale, this framework will take
travelling on multiple airlines and intermodal partners to the next level, addressing the challenges
outlined above.
Within the ferry industry the FerryGateway initiative has brought forward an open source and free to use
worldwide standard for communication between ferry operators and agent reservation systems. It
provides a standardised set of messages that enables reservations, amendments and cancellations of
ferry trips including all products and services on board. It is stateless, SOAP-based and is defined using
XML-schemas.
Learnings from the above in our context are:
— There should be a direct and simple way for Retailers and Suppliers to exchange offer details,
including their travel guarantees and travel conditions.
— There should be enough room for Retailers to bear the responsibility of direct relationships with
both Customers and Suppliers.
— All relevant stakeholders should have access to the full set of applicable products and fares
available.
5.4 The definition of "booking" or lack thereof
Transmodel (EN 12896) has defined “booking” in its part 5 as the placing of a reservation to use a specific
transport service — but not necessarily entailing a purchase of a ticket.
However, the term ‘booking’ is mostly avoided in this document as it is used differently across the
stakeholders of the CoRoM project in different contexts that vary according of their diverse backgrounds.
For example, depending on the types of mobility services they work with and the local context they
experience, different meanings for ‘booking’ include:
— A long-term reservation of some resource, A purchase of a train ride,
— A written agreement between two parties, with two deliverables, one on each side,
— A seat reservation,
— The intended consumption of a trip,
— An act of reserving accommodation, a ticket, etc. in advance,
— An agreement that has been written down (‘hit the books’),
— The entire process of reserving or securing a service, resource, or accommodation for a particular
date or time.
The term "booking" is sometimes used as a noun, in other cases is related to the process of booking.
TSI Telematics uses the term "reservation" as an authorisation to assess as a service and "booking"
rather as synonymous with "selling".
In MMTIS "booking" is used in the context of information provided by a fare query (i.e., by the delivery)
and related to
— WHEN to book (purchase window, validity periods),
— WHAT choice of parameters is possible (space-related parameters: e.g., routing restrictions, zonal
sequence or time-related parameters: e.g., minimum stay).
In TOMP, 'booking' is used in v1.x. as a container term for offers. In TOMP v2.0, it will closely be related
to Transmodel, and the term 'booking' will be replaced by terms related to the Transmodel SALES OFFER
PACKAGE.
The OSDM specification says: "The booking represents the offers that have been selected and turned into
a booking on request to the provider of the offers".
For Transmodel: "booking" is synonymous with "a process of confirmed reservation of an asset", an
asset being an access right to a service, a service or specific equipment like a seat, a bike, etc. "Confirmed"
has to be understood as: providing a record. Thus "booking" has to be understood as "process of
sales/purchase excluding payment" (payment is a separate process).
If mentioned in this document, booking is understood as "purchase", which is also the admitted term of
the Transmodel concept.
5.5 Methodology
An API (Application Programming Interface) is a set of rules and tools that allows different software
applications to communicate and exchange information in a standardised way. It defines the methods
and data formats that applications can use to request and exchange information.
Designing an effective and robust API — whether for web services, frameworks, libraries, or other
applications — requires a structured approach entailing the following steps:
— Gather Use Cases and Functional Requirements
— Define the Data Model
— Design the API Interfaces
— Determine Resource Representations
— Assign Operations
— Implement Error Handling & Validation
— Document the API
— Test and Iterate
This document focuses on steps 1 (Gather Use Cases and Functional Requirements) and 2 (Define the
Data Model).
Before drafting the guidelines for multimodal travel purchase APIs based on Transmodel, the CoRoM
project team decided to analyse existing APIs. A detailed technical mapping table of the APIs queries has
been elaborated to drive this document. The choice of which API to select for analysis was based on three
main criteria:
— The API is used in a multimodal context, which covers any modes of transportation from
conventional public transport to long-distance rail, but exclude air travel,
— The API has already been adopted by several stakeholders (i.e., it’s most probably implemented
at least once) and is different enough from the others (i.e., it has functions not covered by other
APIs),
— The API is European.
The selected APIs were:
— BoB,
— Entur API,
— FerryGateway,
— OSDM,
— TAP TSI,
— TOMP-API,
These APIs are detailed in Annexes A to F.
Attention is drawn to the fact that other APIs exist in European context (e.g., VDV used in Germany,
Poland, Czech Republic, etc.), but they did not meet all the criteria above-mentioned. And some ongoing
initiatives aims to specified national distribution APIs like in France, where a standardisation working
group is dedicated to working on interfaces between transport ticketing systems and especially on "fare
collection", how to sell and issue a ticket to a customer, aligned with CoRoM recommendations.
For all the selected APIs, the same methodology was applied:
— The mapping of their concepts to Transmodel, as the reference model,
— The identification of the commonalities between the API and Transmodel as to both:
o Queries needed to provide a coherent set of online processes for a multimodal travel
purchase API,
o Data used in the queries
— An analysis of the commonalities and differences in the above was then used to identify additional
concepts needed in Transmodel to allow the building of a multimodal travel purchase API.
The outcome of this document aims to support interoperability of APIs provided they are aligned around
Transmodel concepts. The evolution of each API will show the usefulness of different modes.
5.6 Exclusions
This document does not cover the following functions, that are variously associated with purchase and
reservation:
— Journey Planning, considering it is a prerequisite action and is covered by the Open API for
distributed Journey Planning (OJP) (TS 17118),
— Trip execution, i.e., travel by the passenger, considering it is an activity conducted after purchase,
— Ancillary activities such as manual assistance (customer service) for purchase or reservation
activities,
— Payment, considering it is a well understood generic activity,
— Validation and control of travel documents, considering it is an activity conducted after purchase
(though we note it will need data passed from the purchase transaction),
— Registration of a transport user (e.g., creation of an online account, against which travel purchases
can be recorded), considering it is a well understood generic activity,
— Security management, considering it is a prerequisite action,
— Rights management (mostly related to Intellectual Property Rights in the data and contractual
agreements to use it), considering it is a separate concern – the allocation of specific
responsibilities to specific actors is however addressed.
5.7 Preliminary conclusions
Based on the analysis of the above-mentioned APIs and the work done within the CoRoM project, some
preliminary conclusions have been made as to what to expect from a purchase & reservation API
specification supporting multi-modal cross-Europe travel.
Such purchase and reservation API specifications is expected to:
— Be “basic” enough to support all forms of public transport in that it prescribes an easily achievable
minimum level of implementation, while at the same time permit a more advanced use for more
complex products and interactions where needed,
— Support combining offers from different distributors and aggregators. This requires support for
a two-stage commit process in order to avoid customers ending up with having paid for “half a
ticket”, e.g., for just one leg of an incomplete trip, without being able to secure onward travel,
— Be used as basis for interaction on all levels of interaction between the various actors:
o Traveller to Retailer, Distributor, Aggregator, or Carrier,
o Retailer to Distributor, Aggregator, or Carrier,
o Distributor to Carrier,
— Give access to the full set of applicable products and fares available, needed to support the
inclusion of local public transport offers within a multimodal travel offer (e.g., a pass for local
public transport as an add-on to a long-distance rail fare), whenever relevant for the travelling
party,
— Support the automated handling of travel guarantees and travel redresses, which implies clarity
on:
o Who is travelling together (i.e., who is the travel party), so as not to break them up for a
given travel redress,
o Contact information for whenever a travel guarantee fails.
Obviously, the API specifications is expected to use unambiguous and coherent terminology. The
suggestion is to use Transmodel EN 12896, Public transport - Reference data model as the basis, and
propose extensions to the related CEN group if needed.
6 Multimodal travel purchase APIs basics, roles and use-cases
6.1 Basics
Learnings from the purchaser’s perspective, there are three main stages involved in buying the most
optimal solution to travel from an origin to a destination in a multimodal/multi-distributor scenario:
1/ Planning the trip: Asking what possible options are available to travel, considering only combined
timetable-data from different operators — available from National Access Points in accordance with
MMTIS. At this stage price and reservation-availability information is not mandatory.
2/ Asking for Offers: from one or several different Distributors, for selected Trips (or subsets of Trips)
returned in the above Trip planning response. In this stage a price (e.g., € 195) and a preliminary
availability (e.g., only 5 seats remaining/fully sold out) of the requested Trip-option or a part of should
be provided. At this stage it is not required that the offered product is exclusively locked to the requestor.
Note that separate Offers covering only certain parts of a Trip can be requested separately from different
Distributors without any connection between them. The Offers can be managed by a Fare calculator, using
various optimisation criteria: for example, most complete solution from start to end, least expensive, best
touristic value, best using my travel pass, best using my commercial profile, etc. Note that all relevant
Fare options are expected to be provided (and any conditions for purchasing or using them).
3/ Purchasing the preferred offer(s): The purchaser, i.e., the end customer (potentially through a retailer
or an intermediate distributor) can decide that it is best to use a combination of offers, from different
distributors, covering different sub-parts of the preferred Trip option. The separate purchases from all
the involved distributors are expected then to be synchronised, such that overall, it is an all-or-nothing
purchase. Thus, the purchase is expected to be preceded by first locking all necessary offers in parallel.
Each of the involved distributors/attributors are expected to lock the respective sub-Trip offer in their
respective inventory for a short period. The successful locking is expected to be reported back allowing
the end customer to finalise the necessary purchases with all the different distributors in parallel. This is
expected to take place as soon as a positive response has been received from all parties. Alternatively, if
one of the distributors does not respond within a given timespan, all purchases should be aborted.
6.2 Roles
Presentation of Transmodel functional roles with definitions and a list of IFM, TAP-TSI and OSDM roles
playing the Transmodel role (partial role between brackets).
Table 1 – Roles – List and definitions
Functional role – Type and sub- Definition IFM, TAP-TSI,
types TOMP-API and
OSDM roles
FARE ORGANISATION ROLE Any corporate role in providing or
managing transport services.
FARE PRODUCT The role, in large networks, of organising IFM: N/A
DISTRIBUTOR ROLE and accounting for the wholesale
TAP-TSI: N/A
distribution of FARE PRODUCTs, as
OSDM: Fare
delegated by the FARE PRODUCT
Provider
OWNER ROLE and to supply products to
(Allocator)
the FARE PRODUCT RETAILER ROLE.

FARE PRODUCT OWNER The role of the organisation which has IFM: Product
ROLE commercial ownership of a FARE Owner
PRODUCT and is responsible for
TAP-TSI: Fare
specifying pricing, usage conditions and
Provider
commercial rules for the product, for
OSDM: Fare
ensuring there are processes for
Provider
marketing and retailing the product,
(Allocator)
customer payment, control and
validation, back-office accounting and
settlement and for customer service.
FARE PRODUCT ISSUER A role of an organisation introduced IFM: N/A
ROLE when there are a large number of fare
TAP-TSI: Issuer
product owners and a large number of
OSDM: Allocator
distributors. The FARE PRODUCT
ISSUER ROLE makes a portfolio of
products available to a product
distributor to be sold via product
retailers to TRANSPORT CUSTOMERs.
FARE PRODUCT The role of being an agent of a FARE IFM: N/A
ATTRIBUTOR ROLE PRODUCT OWNER, i.e., the role of an
TAP-TSI:
intermediary organisation to whom
Distributor
certain responsibilities have been
OSDM: Allocator
delegated by the FARE PRODUCT
(Fare Provider)
OWNER, for instance to provide the
technical implementation of the
products defined by the FARE PRODUCT
OWNER.
NOTE  in TAP-TSI, corresponds to the
distributor role, in charge of all product
combinations (e.g., fares without yield
management and yield managed fares).
FARE PRODUCT RETAILER The role of an organisation to sell IFM: Product
ROLE products to TRANSPORT CUSTOMERs, as Retailer
authorised by a FARE PRODUCT OWNER
TAP-TSI: Issuer,
ROLE. The FARE PRODUCT RETAILER
Retailer
Functional role – Type and sub- Definition IFM, TAP-TSI,
types TOMP-API and
OSDM roles
ROLE can be undertaken by the same OSDM: Retailer
party as the FARE PRODUCT OWNER
TOMP: MP
ROLE, the ACCOUNT PROVIDER ROLE, or
(MaaS Service
a secondary outlet such as a TRAVEL
Provider)
AGENT or, newsagent, or other third
party, etc.
NOTE  In TAP/TSI, Issuer and Retailer
roles are authorised by Railway
undertakings (Fare Providers).
FARE DATA COLLECTOR The role of collecting and forwarding IFM: Collection
ROLE fare data between the various parties and Forwarding
concerned with product delivery, such as (set of functions)
PRODUCT RETAILER, PRODUCT
TAP-TSI:
OWNER, etc. Can be undertaken by a
Distributor,
separate intermediary.
Ticket
Controlling
Organisation
NOTE  In TAP-TSI, the distributor role
includes collecting and providing data OSDM: Allocator,
about issued tickets (including related Ticket
information like spot allocation). Controlling
Organisation
TOMP:
Transport
operator
FARE REGISTRAR ROLE The ADMINISTRATIVE ORGANISATION IFM: Registrar
ROLE of coordinating the issue of unique
TAP-TSI: Fare
registration codes (for example, by
Provider,
determining rules for generating unique
Registrar Body
codes) for data linked to fare
OSDM: Fare
management such as FARE CONTRACTs,
Provider,
TRAVEL DOCUMENTs, etc.
Registrar Body
FARE REGISTRAR ROLE The ADMINISTRATIVE ORGANISATION IFM: Registrar
(FARE CONTRACT & TRAVEL ROLE of coordinating the issue of unique
TAP-TSI: Fare
DOCUMENT) registration codes (for example, by
Provider
determining rules for generating unique
OSDM: Allocator,
codes) for data linked to fare
Certification
management such as FARE CONTRACTs,
Body
TRAVEL DOCUMENTs, etc.
FARE SECURITY MANAGER IFM: Security
ROLE Manager
The ADMINISTRATIVE ORGANISATION
TAP-TSI: N/A
ROLE of establishing and coordinating a
OSDM:
security policy for fare data across the
Certification
provider organisations, and of the
Body
certifying and auditing of organisations,
Functional role – Type and sub- Definition IFM, TAP-TSI,
types TOMP-API and
OSDM roles
applications, etc., for their conformance
to the security policy.
TRAVEL ORGANISATION ROLE The role of an ORGANISATION in TOMP:
providing any kind of travel related
...