Home

Welcome to the TOMP-API wiki!

This WIKI contains the lastest version of the TOMP-API. To facilitate the implementation of the API, we've made some supportive documentation with some examples/explanations. Not all scenarios are reflected in them, but they'll probably be of value.

• Planning phase
• Booking phase
• Trip execution phase - start
• Trip execution phase - on route
• Trip execution phase - end
• Operator information
• Payment

FAQ

• Frequently Asked Questions

Implementation - how to's (Q&A)

• How do I start a TO
• Semantic versioning in the TOMP API
• Simple Operator information
• Display all assets on a map and book one of them
• Scan for bluetooth devices nearby and book one of them
• Specify pick up or drop off locations
• Simple planning & booking phase
• Planning phase prices
• be GDPR compliant

Implementing operators

• How do I implement a taxi operator
• How do I implement a bike operator
• How do I implement a public transport operator
• How do I implement a parking facility (offstreet)
• How do I implement a micromobility operator

Contributing

TOMP-API is licensed under the Apache License 2.0, an open source license. Contributions are very welcome! Ways to contribute include:

• Posting issues with suggestions for new features, bug reports or other changes you'd like to see
• Contributing code, see How to contribute code

Current version: 1.0.0 - Dragonfly

• illustrative document
• https://app.swaggerhub.com/apis/TOMP-API-WG/transport-operator_maas_provider_api/

Updates

1.0.0 - Dragonfly
Feature requests

• #200 Added product description
• #209 Being able to request a payment/journal-entry on a booking basis
• #221 Add availability at a particular station/hub and calendar per station/hub
• #222 Extended endpoint legs-event with 503-retry after for temporary malfunctioning.
• #234 GDPR aspect: Rotation of asset ID after rental
• #218 Added sequence diagrams

Change requests

• #215 subscription endpoint doesn't need complex request body
• #231 rename field "properties" in Asset; it is a keyword

Bugs

• #219 claim extra cost shouldn't be a PATCH
• #228 too many fields in booking object
• #239 Reintroduce REJECTED state as booking state

0.9.0 - Release Candidate Dragonfly
We've taken the lessons learned so far and applied them in the API. Also used reviews to make it better. Major changes: support module has been reviewed (#146), some simplification (#176) and a new endpoint to facilitate a self describing API (#180).
Feature requests

• #147 Using a single url for multiple organizations
• #167 conditionRequireBookingData lacks name
• #159 Use ISO 8601 (RFC3339) timestamps in JSON body
• #180 Self describing facilities

Change requests

• #176 PlanningOptions has duplicate items and in general could use a cleanup
• #144 renaming "provide-ids" in /planning-options
• #146 Support endpoint refactoring
• #134 Restructure error object duplicate / #163 [FEATURE REQUEST] Specify errors WT1

Bugs

• #186 Example timestamp is in seconds, not in milliseconds
• #165 mandatory fields

0.5.0 Breaking changes

• #136 Standardized API error breaking change request
• #133 kebab-case to camelCase breaking change request
• #120 composit-leg should be named composite-leg breaking bug
• #114 Remove items from asset and asset-type (#110) breaking change request
• #111 Consistency in the Operator Information breaking
• #126 Coordinates instead of coordinate

0.4.0

• #93 Trip Execution: ETA is missing change request question
• #115 Add GBFS attributes to station information change request
• #119 Adding personal info change request
• #105 Multiple fields in "type-of-asset" in /planning-options response should not be on type level bug change request
• #112/#116 Missing geometries in Operator Information change request

0.3.1: bugfix

• #131 key-value only contains key.... (bug)

0.3.0: semantic versioning adopted

• #102 Add semantic versioning

1.2: confirmed 1.1.2. No real changes, except for removing server, contact etc.

1.1.2: more payment phase, but also include the first implementation impacts
Includes:

• Operator information:
  1. missing available assets in operator information (#83, #96)
• Planning options:
  1. overlays can now be handled in a composit-leg (#59)
  2. fare scales (#89)
  3. amount of available assets added (in case of type-of-asset results) (#91)
• Payment:
  1. extra condititions for payment (upfront-payment and pay-when-finished) and optional bank account (#85)
  2. distance or time based scales (#87)
  3. in journal entries time and distance are reported (#87)
  4. composit leg is supported (88)
• some small adjustments:
  1. missing MP/TO id (#86)
  2. geojson to communicate the leg (reducing the message length) (#63)
  3. when booking some extra information could be required (physical pick-up/drop-off addresses, e-mail addresses, date of birth). (#94, #97)
  4. extra modalities (moped, step)

1.1.1: goal: first set up for the payment phase (batch payment). Includes:

• payment phase
• 'Postponed commit' scenario
• Transport types clarified
• More precise description of travellers for more accurate planning
• return conditions
• some smaller issues:
  1. corrected example values
  2. merge 'mode' and 'type-of-asset'

1.1.0: major changes, not compatible with 1.0.0.
Includes now:

• planning phase
• booking phase
• trip execution phase
• REST implementation
• first setup webhooks
• first setup authentication
• one swaggerfile to maintain
• first setup TOMP API for dummies (WIKI)
• all kinds of smaller issues:
  1. adjustments on the availability check (timestamp, number of passangers, request of ID's, 'woordenboek reizigers'
  2. longitude/latitude is now everywhere in an object instead of array
  3. generic message header
  4. uniformity

Participants

• Cargaroo
• InTraffic/TURNN
• PAXX
• DAT.Mobility/Kyyti/GoOV
• CITYWAY
• GVB
• Radiuz and Amaze
• Donkey Republic