Traceability of a journey from search results to Booking object (deeplink booking)

[pierrecamilleri]

Before making any concrete API spec proposition, I would like to have your input on what could prevent the following mechanism :

• It is not obvious to me why a Booking feed with MaaS Connect may be incompatible with tracing a journey from search to booking.
• The idea behind this is that the transport operator should be able to provide in the booking feed sort of Booking objects (not necessarily exactly the current one) that contain the IDs of the booked journeys (any of {driver, passenger}JourneyId).

Technically, I have two ideas in mind:

1. The journey ID of the search is provided by the transport operator (TO), is there a reason why it cannot be provided again for a specific booking the same way? The MaaS can then reconcile if the journey ID corresponds to any search result, or assume it is a new unknown journey otherwise.
2. If the first option does not work, here is a second try: in the search results, the transport operator provides the webUrl alongside the journeyId. Couldn't he embed the journeyId in the URL to recover it in the booking phase ? If the user makes the reservation, then the Transport Operator is able to link the booking with the journeyId. Otherwise (= default / empty journeyId in Booking), the MaaS should assume it is not the journey that was initially intended. I realize by writing this that the implementation may not be obvious (for instance, what happens if the user navigates on the TO app, to come back to its initial choice after all? Can the journeyId be reliably tracked then?)

[ghislainfabmob]

For me the issue should be stated this way: we'd like to have two-way communication between MSP and MaaS during a booking/trip lifecycle, from the redirection to MSP app to the end/billing/termination of the booking/trip. This adds value to the deeplink solution, but it would also be useful in full-API integrations. It means that MSP want to push fresh information to the MaaS about an active booking (new events) and expect that MaaS will take these events into account as far as possible (which means listen to these events and act on them, at least store them). On the other end some MaaS apps need/would like an option to request status updates on a given journeyID or a given user. The latter one (journeyID) opens interesting opportunities for cooperation. When MSP and MaaS agree on cooperation and that a user has linked its MaaS <-> MSP accounts he can allow (through OIDC/MaaS Connect) the transfer of information on its bookings to the MaaS apps.

[pierrecamilleri]

Cf #28 for the related use case.