The Journey-Service is a RESTful "Journey-Planner" facade abstracting public transportation routing and planning for a set of SBB Switzrland relevant underlying systems, such as Hafas, HIM, CUS, INFO+, DiDok, CAPRE, FOS, PLABE, OccupancyPrognosis, NOVA etc.
The main Use Cases are:
- Finding
Place
(aka OJPLocation
), such asStopPlace
resp. (stations for public transport trains, busses, tramways, ...),AddressPlace
andPoiPlace
(Points of Interest (POI)). - Finding concrete journeys (
Trip
,DatedVehicleJourney
) as passenger-information. - Finding some SBB specific additional info (such as
Trainformation
s, Realtime monitoring etc)
A set of implemented SBB Business Rules (such as delays, platform changes,...) guarantees that consuming channels may display consistent data.
If you are new to journey-planning with SBB, consider general standards as mentioned in chapter "Routing Standards in "Public Transport"
- Strategic usage for SBB and partners: Journey-Planner systems are a business critical core functionality at SBB. Plenty of Consumer applications use it (like sbb.ch, SBB Mobile, SBB Ticket vending machines, SBB Group reservation and Capacity management, SBB B2P and many others.
- Business aspects: all consumer get the same information (we work hard to enhance quality and continuous feature innovation).
- Easy usage by consumer developers: Our APIs are RESTful and documented, Openapi 3 generated ApiClient capable.
- Follow existing standards but simplify and adapt to enhance time-to-market of new customer-information features
Check the blog: https://developer.sbb.ch/apis/journey-service/blog
To stay up to date about new features or adjustments we highly advise you to use the RSS feed. Please follow the following instruction to insert the RSS Feed of the Journey-Service Blog: Instruction RSS Feed
See SBB staff release notes. Because J-S heavily relies on the Journey-Assistant library, also those J-A Release-Notes might reveal some important updates.
All Services (short abstract, request-parameters, response-models) are documented directly by swagger-annotations, therefore the documentation below is reduced to the max and is hopefully rarely necessary for v3 API understanding in most cases.
See Business Aspects