Using the FARE PRODUCT catalogue, the TRANSPORT CUSTOMER chooses one or more catalogue items and enters additional information to allow determining the best offer (FARE PRODUCT, SALES OFFER PACKAGE, the related PRICE and TRAVEL GUARANTEEs).
After having received trip proposals from the trip planner, the TRANSPORT CUSTOMER chooses one of them and requests information on the corresponding TRAVEL PACKAGE (FARE PRODUCTs, SALES OFFER PACKAGEs, PRICEs and TRAVEL GUARANTEEs).
When choosing a TRAVEL PACKAGE for a specific trip, with or without making a reservation, the TRANSPORT CUSTOMER wants to be informed about the availabilities of each solution and their options before making a purchase.
The customer may or may not place a reservation, temporarily or confirmed. An availability check may be done in advance to preplan (e.g., to check availability of product or seat) or also at the time of travel to check the current availability of assets.
When a TRANSPORT CUSTOMER has selected one or more PASSENGER FARE OFFERs and any required choices for a TRAVEL PACKAGE, he/she proceeds to the purchase.
UC5.1 “After-sale request by the traveller” Once a purchase has been made, a TRANSPORT CUSTOMER can request an after-sale action at any moment during travel, but the focus here is on the process before the travel.
UC5.2 “Change under the responsibility of any providers involved in the trip for a through ticket (not the traveller)” Change in the previously advertised services (re-accommodation)
UC6.1 “Change by the traveller” After-sale request by the traveller.
After the trip departure, a personal event (e.g., a change of plans, sickness, a forgotten meal, missed connection) can lead the traveller to modify his/her passenger accommodation or to cancel or extend the trip or a part of the trip.
UC6.2 “Change under the responsibility of any providers involved in the trip (not the traveller)” Disruptions (e.g., accidents) and related trip modifications made by the OPERATOR may modify the trip impacting SALES OFFER PACKAGEs, reservations, final prices, TRAVEL GUARANTEEs and
TRAVEL DOCUMENTs.
A TRANSPORT CUSTOMER can consult his/her CUSTOMER ACCOUNT and perform some actions on FARE PRODUCTs-SALES OFFER PACKAGEs he/she has purchased.
On ticketing system with urban and interurban transport modes (metro, bus, tramway, coach, cable, regional rail), they are specific use cases linked with thoses particularities : complex fare products, yearly pass with payment terms and instalments, transfers with fee or not, cutomer profiles (social rights, reduction cards, ...), group tickets,.. The travel document are also various : contactlexx card, paper ticket, QRcode, mobile application, embedded card, bank card. It is not a full list.
See ticketing.md for the complete list
OSDM (Open Sales and Distribution Model) covers the full retail journey from offer search through booking, fulfillment, after-sales, and master data provision. It extends beyond the CoRoM scope into OSDM-specific areas such as graphical seat reservation, on-hold offers, the exchange flow, travel accounts, on-demand services, complaints, and API-driven webhooks.
See osdm.md for the complete list with endpoint references and uniqueness notes.
TOMP-API (Transport Operator MaaS Platform API) targets shared-mobility and MaaS integration. In addition to standard offer/booking/after-sales flows it uniquely covers physical asset execution (lock/unlock, ETA, driving support), leg lifecycle management, driver's licence validation, deposit handling, and push notifications.
See tomp-api.md for the complete list with endpoint references and uniqueness notes.
OMSA (Open MaaS Standard API) follows OGC API Processes conventions and covers the full mobility service lifecycle — authentication, discovery, offer search, traveller management, asset assignment, purchase, after-sales, travel documents, and payment. Together with TOMP-API, it is one of two in-scope standards that specify the OAuth 2.0 token endpoint (POST /oauth/token) explicitly in-spec; TOMP-API additionally provides POST /connect/token for OpenID Connect.
See omsa.md for the complete list with endpoint references and uniqueness notes.
FerryGateway is an XML-based (request/response message pairs, not REST) standard for ferry booking. It covers sailing search, vessel timetables, route and port reference data, passenger and vehicle type catalogues, cabin and berth accommodation, ancillary services (meals, on-board), land/transfer connections, cancellation charges, invoicing, promotional codes, and QR-code travel documents.
See ferrygateway.md for the complete list with message-pair references and uniqueness notes.
BoB (Backend of Backend) is an intentionally narrow B2B ticketing interoperability layer. It handles booking calls between a distributor and an operator backend and the exchange of signed Mobile Ticketing Blocks (MTBs) for validation. It is not a full booking API and deliberately omits trip search, offer search, seat reservation, and customer account management.
See bob.md for the complete list with endpoint references, uniqueness notes, and an explicit out-of-scope section.