Separate sources provide current data
Vendo and Movas provide station search, fares, connections and fare details. DB Navigator's Vendo system adds delays, platforms, departure boards and train runs.
bahn.de journey guidance provides carriage order. Further interfaces search journeys and fares from FlixTrain, Westbahn, Leo Express, GoVolta, European Sleeper, Snälltåget, MÁV, PKP Intercity, SNCF Connect and ČD. Ticket and seat-reservation shops are checked separately for the same already selected journey.
Compact station and route files derived from public booking pages determine whether a provider fits the route before a request. Each provider has its own request limit. If one interface changes or fails, only that result remains unknown; DB search and other providers continue.
After your approval, the optional trip import reads journeys from the DB account. The password remains with DB, and the app changes neither bookings nor account data.
Processing stays on the device
The installed app requests current data directly from providers. No Bahnsparer server processes itineraries or fares.
Shared request control limits parallel calls and becomes more conservative under load, preventing several fare checks from creating uncontrolled requests.
An ordinary web service cannot request these sources directly in the same form, so the app uses native network access on iOS and Android.
Missing data remains visibly missing
Incomplete fare
A fare covering only part of a route cannot determine the lowest-priced travel day, a price alert or a split-ticket comparison. A provider fare from another station counts as a total only after priced rail connections before or after it are included.
No invented answer
If delay data is missing, the app does not show zero minutes. If a provider comparison fails, the day is not treated as having no such connection.
Each source is processed separately. If carriage order fails, fares, connections and reliability values remain available.
Historical data does not come from live search
The DB Timetables API provides the basis for historical reliability. An open monthly dataset prepares the data under CC BY 4.0. The app receives the finished local model and contacts no model server during a search.
Each monthly build pins the dataset to one immutable revision, so the file list and monthly files come from the same state. The finished model names that revision and expected data structure. Arrival and departure cancellations are read separately, and a cancellation in either field counts.
The current rail interfaces are not guaranteed as stable APIs for third-party apps and may change. Prices remain non-binding; booking takes place with the relevant provider.
Data coverage, training and measured model quality are explained in the model documentation.