When you travel in a MaaS way, you normally use assets from Transport Operators. Sometimes, you might need other things related to the asset (like a helmet on a fast bike).
And then this question pops up: is the TOMP-API able to incorporate these ‘add-ons’ or ‘ancillaries’ into the process in a generic way?
Up to the current version 1.2.0, the answer has been no. But in the next version, we’re going to facilitate add-ons as an integral part of the TOMP-API.
We are going to extend the current way of planning and booking to facilitate add-ons. The extension will also impact the provisioning of general and payment information.
In the planning phase, the TO will be able to request add-ons. These ancillaries will then be integrated into the planning options, keeping the booking unchanged. Booking or cancelling add-ons like Helmets or child seats just before starting the leg is common and to be expected. This is why we are thinking about adding a specific endpoint facilitating this functionality. And, of course, the ancillaries should be listed in the operator part of the API. The payment part doesn’t have to change at all; the specification of the ancillaries can already be exchanged in the current setup.
It looks like adding ancillaries will impact the operator information, the planning, and the trip execution endpoints. This covers a big part of the building blocks of the TOMP-API. Luckily, these are non-breaking extensions. This means that a 1.3.0 implementation should be able to handle a message from a 1.2.0 implementation, without technical issues or complications. Vice versa, communication with a newer implementor should also work seamlessly, but of course, the newly introduced concepts can not yet be handled.
Editor: T.A. Groen