Was versteht man unter multimodalem Bedarfsverkehr?

Multimodaler Bedarfsverkehr bezeichnet Mobilitätsangebote, bei denen Rufbusse, On-Demand-Shuttles oder Anrufsammeltaxis als integrierter Baustein einer übergreifenden Reisekette betrieben werden – mit einer einzigen Buchung über verschiedene Verkehrsträger hinweg.

Welche technischen Standards sind für multimodale Buchung notwendig?

Drei Ebenen sind entscheidend: REST-APIs nach OpenAPI-Spezifikation, standardisierte Fahrplandaten im GTFS-Format und ein übergreifendes Single-Sign-On auf Basis von OAuth 2.0 und JWT.

Kann maas.maker mehrere Betriebsgebiete vereinen?

Ja – die mandantenfähige Architektur ermöglicht es, mehrere eigenständige Betriebsgebiete verschiedener Gemeinden oder Verkehrsunternehmen auf einer Plattform zu betreiben, mit eigenem Branding und eigener Tarifstruktur.

Technologie

Multimodaler Bedarfsverkehr & Multimodale Buchung

Warum multimodaler Bedarfsverkehr die Mobilitätswende erst möglich macht und wie die maas.maker Plattform multimodale Buchung technisch umsetzt – von der OpenAPI-Schnittstelle bis zur VAO-Anbindung.

Demo anfordern Alle Beiträge

17. Mai 2026 Veröffentlicht

15 Min. Lesezeit Lesedauer

Multimodal Bedarfsverkehr OpenAPI VAO GTFS

Wer in Österreich oder Deutschland über nachhaltige Mobilität nachdenkt, stößt unweigerlich auf dasselbe strukturelle Problem: Der Linien-ÖV schließt die Lücke nicht. Er fährt nach Fahrplan, auf festen Routen, in Taktzeiten, die ländliche Nachfragestrukturen nicht abbilden können. Bedarfsverkehre – Rufbusse, On-Demand-Shuttles, Anruf-Sammeltaxis – füllen diesen weißen Fleck. Aber sie tun es bislang meist isoliert: eine App pro Region, ein Login pro Dienst, keine Verbindung zum Linienverkehr, keine übergreifende Buchungslogik.

Diese Fragmentierung ist das eigentliche Hindernis auf dem Weg zur echten Mobilitätswende. Menschen wechseln nicht freiwillig vom Auto auf den ÖPNV, wenn sie für eine Reisekette von A nach B drei verschiedene Buchungskanäle, zwei Apps und zwei unterschiedliche Bezahlsysteme benötigen. Das Ziel muss sein, was Forschung und Politik bereits seit Jahren fordern und was die FFG mit Programmen wie „Mobilität der Zukunft" und der Ausschreibung „Digitale Transformation in der Mobilität" gezielt fördert: multimodale Buchung aus einer Hand, nahtlos über Regionen und Verkehrsträger hinweg.

Die maas.maker Plattform hat genau diese Vision technisch umgesetzt. Heute.

Verkehrsträgerübergreifende Verbindungsauskunft

Wenn ein Fahrgast eine Reise von Gemeinde A nach Stadt B plant, sieht er nicht nur den verfügbaren Bedarfsverkehr. Er sieht die vollständige multimodale Kette: den Rufbus von der Haustür zur Bahnhaltestelle, den Zug bis zur Stadtgrenze, den On-Demand-Shuttle ins Zentrum – alles in einer einzigen Suche, mit Echtzeit-Verfügbarkeiten und einem gemeinsamen Preis.

Regionsübergreifende Buchung mit einem einzigen Account

Ein Fahrgast, der heute in Kärnten und morgen in Salzburg unterwegs ist, soll nicht zweimal ein Konto anlegen und zweimal zahlen müssen. Single Sign-On mit zentraler Authentifizierung ermöglicht die Nutzung aller angebundenen Bedarfsverkehre unter einer Identität – unabhängig davon, welche Gemeinde oder welcher Betreiber den jeweiligen Dienst verantwortet.

Standardisierte Schnittstellen für systemübergreifende Integration

Die Plattform muss mit dem gesamten digitalen Ökosystem sprechen können: Verkehrsauskunftssysteme, Ticketing-Backends, MaaS-Plattformen, Verbundsysteme, externe Buchungsportale. Das gelingt nur über offene, dokumentierte Standards – nicht über proprietäre Insellösungen.

Alle drei Dimensionen sind in der maas.maker Plattform produktiv implementiert.

OpenAPI-Schnittstellen nach aktuellem Standard

Die maas.maker Plattform exponiert ihre Kernfunktionen vollständig über standardisierte REST-APIs nach OpenAPI-Spezifikation. Jede Funktion – Verbindungssuche, Buchung, Fahrtenstatus, Benutzerverwaltung, Zahlungsverarbeitung, Reporting – ist über...

Single Sign-On mit zentraler Authentifizierung

Die maas.maker Single-Sign-On-Architektur löst das Fragmentierungsproblem auf Plattformebene. Ein Nutzerkonto, einmal angelegt, gilt über alle angebundenen Betriebsgebiete hinweg. Die Authentifizierung erfolgt nach aktuellen Sicherheitsstandards...

KI-gestützter Dispositionsalgorithmus

Das technisch anspruchsvollste Element: Wenn ein Fahrgast eine Verbindung bucht, die mehrere Verkehrsträger kombiniert, muss der Algorithmus die Bedarfskomponente in eine reale Zeitkette einfügen – mit Anschlusssicherung, Pufferzeitmanagement und...

Die maas.maker Plattform ist als mandantenfähiges System aufgebaut: Mehrere Betriebsgebiete – unterschiedlicher Betreiber, Gemeinden, Bundesländer – können auf derselben technischen Infrastruktur betrieben werden, ohne ihre operative Eigenständigkeit aufzugeben. Jeder Betreiber hat seinen eigenen abgeschirmten Verwaltungsbereich, seine eigene Tarifstruktur und sein eigenes White-Label-Branding.

Verbindungssuche über Betreibergrenzen

Fahrgast sucht von Haltestelle X (Betrieb A) nach Haltestelle Y (Betrieb B). Die Plattform zeigt die kombinierte Verbindung an, inklusive Umstiegshinweis und Gesamtreisezeit.

Nahtloses Buchen beider Segmente in einem Vorgang

Statt zwei separater Buchungen in zwei Apps wird die gesamte Reisekette in einer einzigen Transaktion gebucht. Zahlung, Bestätigung und Fahrttracking laufen über eine einheitliche Oberfläche.

Übergreifendes Reporting für Aufgabenträger

Landkreise und Bundesländer erhalten eine konsolidierte Datenauswertung über alle Betriebsgebiete hinweg – ein zentrales Instrument für evidenzbasierte Verkehrsplanung.

Die österreichische Forschungsförderungsgesellschaft FFG hat Multimodalität und Digitalisierung im Bedarfsverkehr seit Jahren als strategische Priorität definiert. Das Programm „Mobilität der Zukunft" und die aktuelle Ausschreibung „Digitale Transformation in der Mobilität" (mit einem Fördervolumen von 6,6 Millionen Euro allein für 2025) richten sich explizit an Lösungen, die ÖV-ergänzende Mobilitätsdienste in die multimodale Beauskunftung einbinden.

Das FFG-geförderte Forschungsprojekt PRIMA (2023–2025) hat evidenzbasierte Planungsgrundlagen für integrierten Bedarfsverkehr entwickelt und am Beispiel des Tennengau Shuttles gezeigt, wie Mikro-ÖV als vollwertiger Teil einer multimodalen Reisekette operativ umsetzbar ist.

Für Betreiber und Gemeinden, die FFG-Förderungen beantragen, ist der Einsatz einer Softwarelösung, die diesen Anforderungen entspricht, ein direktes Qualitätsmerkmal für die Förderfähigkeit. Die maas.maker Plattform erfüllt mit OpenAPI, GTFS-Datenintegration, VAO-Anbindung und mandantenfähiger Architektur exakt diese Anforderungen.

Ein zentraler Baustein der multimodalen Buchungsarchitektur ist die direkte Anbindung an die Verkehrsauskunft Österreich (VAO). Über diese Integration werden Bedarfsverkehrsangebote als vollständige ÖPNV-Verbindungen im gesamtösterreichischen Mobilitätsnetz sichtbar.

Wer auf val.at oder einer der zahlreichen Apps, die auf VAO-Daten zugreifen, eine Verbindung sucht, sieht den maas.maker-Rufbus als buchbare Option – neben dem Regionalbus, der Regionalbahn oder dem Fernverkehr. Der Bedarfsverkehr wird nicht als Sonderform, sondern als gleichwertiger Verkehrsträger in der intermodalen Routinglogik behandelt.

Zusätzlich unterstützt maas.maker die Anbindung an die Gesamtverkehrsauskunft mit GTFS-Datensätzen: Haltepunktdaten, Tarifzonen, Betriebszeiten und Buchungsparameter werden im standardisierten Format exportiert und können von jedem GTFS-kompatiblen System importiert werden – einschließlich Verbundauskunftssysteme in Deutschland und europäische MaaS-Plattformen.

API-Schicht

Vollständige REST-API nach OpenAPI 3.0-Spezifikation, dokumentiert und versioniert. Separate Endpunkte für Fahrgast-API (Suche, Buchung, Tracking), Fahrer-API (Auftragsempfang, Statusmeldungen), Plattform-API (Konfiguration, Verwaltung, Reporting) und Webhook-Unterstützung für ereignisbasierte Integrationen.

Authentifizierung & SSO

OAuth 2.0-basiertes Single-Sign-On mit JWT-Token-Infrastruktur. Unterstützung externer Identity-Provider (SAML, OIDC) für Integration mit Verbund-Logins oder behördlichen Nutzerkonten. Granulares Rollenkonzept für Fahrgäste, Fahrer, Disponenten, Administratoren und externe Partner.

Dispositionsmodul

In-House entwickelter, preisgekrönter Algorithmus mit parametrisierbaren Pooling-Faktoren, Echtzeit-Routing und Anschluss-Timing-Logik. Konfigurierbar pro Betriebsgebiet: maximale Umwegtoleranz, Poolingfaktor, Mindestbuchungsvorlauf, Fahrzeugkapazitäten.

Datenschnittstellen

GTFS-Import und -Export, VAO-API-Anbindung (Österreich), Schnittstellen zu PAYONE und Stripe für Payment-Integration, CSV/Excel-Export für Reporting.

Mandantenfähigkeit

Vollständige logische Trennung aller Betriebsgebiete bei gemeinsamer technischer Infrastruktur. Jeder Betreiber hat eigene Konfiguration, eigenes Branding, eigene Tarifstruktur und eigene Nutzerverwaltung.

Verkehrsverbünde und Aufgabenträger, die mehrere regionale Bedarfsverkehre unter einem Dach steuern und eine einheitliche Buchungsinfrastruktur für Fahrgäste bereitstellen möchten.

Landkreise und Bundesländer, die Bedarfsverkehre als integralen Teil ihrer ÖPNV-Strategie entwickeln und gegenüber Förderstellen dokumentieren müssen, dass eingesetzte Software interoperable Standards erfüllt.

MaaS-Plattformbetreiber, die Bedarfsverkehr als Baustein in ihr multimodales Angebot einbinden möchten, ohne eigene Disposition und Buchungslogik entwickeln zu müssen.

Gemeinden und Regionen, die ihren Mikro-ÖV aus der Insellösung heraus in ein überregionales Netz einbetten und dabei sowohl Förderkriterien als auch Nutzerbedürfnisse erfüllen wollen.

FAQ

Häufige Fragen zu Multimodalem Bedarfsverkehr

Multimodaler Bedarfsverkehr bezeichnet Mobilitätsangebote, bei denen Rufbusse, On-Demand-Shuttles oder Anrufsammeltaxis nicht als isolierte Insellösung betrieben werden, sondern als integrierter Baustein einer übergreifenden Reisekette. Fahrgäste können in einem einzigen Suchvorgang und einer einzigen Buchung verschiedene Verkehrsträger kombinieren: zum Beispiel den Rufbus von der Wohngemeinde bis zum nächsten Bahnhof, weiter per Regionalbahn in die Stadt und vom dortigen Bahnhof per On-Demand-Shuttle zum Zielort.

Drei Ebenen sind entscheidend: Erstens offene Datenschnittstellen nach OpenAPI-Spezifikation für die Kommunikation zwischen Systemen. Zweitens standardisierte Fahrplandaten im GTFS-Format für Haltepunkte, Verbindungen und Tarife. Drittens ein übergreifendes Authentifizierungssystem mit Single Sign-On auf Basis von OAuth 2.0 und JWT. Die maas.maker Plattform erfüllt alle drei Ebenen.

Ein Fahrgast legt ein einziges Nutzerkonto an und kann damit alle angebundenen Bedarfsverkehrsangebote nutzen – unabhängig von Region oder Betreiber. Das SSO-System basiert auf OAuth 2.0 und JWT-Token-Infrastruktur. Externe Identity-Provider können über SAML oder OpenID Connect angebunden werden, was die Integration mit Verbund-Logins oder behördlichen Nutzerportalen ermöglicht.

OpenAPI ist ein international anerkannter Standard zur Beschreibung von REST-Schnittstellen. Eine nach OpenAPI-Spezifikation dokumentierte API ermöglicht es Drittsystemen – Verkehrsauskunftssystemen, MaaS-Plattformen, Ticketing-Backends –, die Funktionen einer Software ohne proprietäres Wissen zu nutzen. Im Bedarfsverkehr ist das entscheidend: Nur wenn Buchungs- und Dispositionsfunktionen über offene Standards zugänglich sind, können sie in das multimodale Ökosystem eingebettet werden.

Die Plattform ist direkt an die Verkehrsauskunft Österreich angebunden. Bedarfsverkehrsangebote erscheinen als buchbare ÖPNV-Verbindungen und werden in intermodale Routingberechnungen einbezogen. Die technische Grundlage bildet der GTFS-Datensatz. Zusätzlich werden über die VAO-API alle relevanten Linienverkehrsangebote in die Verbindungssuche eingeblendet.

Die FFG fördert im Programm „Digitale Transformation in der Mobilität" explizit Lösungen, die Bedarfsverkehre in die multimodale Beauskunftung integrieren. Die maas.maker Plattform erfüllt mit OpenAPI-Schnittstellen, GTFS-Datenstandard, VAO-Anbindung und mandantenfähiger Architektur genau diese Anforderungen. Für Betreiber ist die Wahl einer konformen Software ein wichtiges Qualitätsmerkmal für die Förderfähigkeit.

Ja – die mandantenfähige Architektur ermöglicht es, mehrere eigenständige Betriebsgebiete auf derselben Infrastruktur zu betreiben. Jedes Betriebsgebiet hat eigene Konfiguration, eigenes Branding und eigene Tarifstruktur. Gleichzeitig können Fahrgäste regionsübergreifend buchen und Aufgabenträger konsolidierte Auswertungen abrufen.

Der in-house entwickelte Algorithmus berücksichtigt Anschlusszeiten zu Linienverkehren, berechnet Pufferzeiten für Umstiege und passt Abholzeiten dynamisch an. Die Kernparameter – maximale Umwegtoleranz, Poolingfaktor, Mindestbuchungsvorlauf – sind pro Betriebsgebiet konfigurierbar. Der preisgekrönte Algorithmus hat sich in über 50 Regionen bewährt.

Ja. Die Datenhaltung erfolgt ausschließlich in Europa. Personenbezogene Daten werden nur im erforderlichen Umfang verarbeitet; das granulare Rollenkonzept stellt sicher, dass Mitarbeitende nur auf notwendige Daten zugreifen können. Auftragsverarbeitungsverträge nach Art. 28 DSGVO werden abgeschlossen.

Der Einstieg beginnt mit einem Beratungsgespräch, gefolgt von Konfiguration, White-Label-Setup, API-Anbindung und Schulung. Die durchschnittliche Implementierungszeit für ein neues Betriebsgebiet beträgt 2 bis 4 Wochen. Die Anbindung an bestehende Systeme (VAO, GTFS, MaaS-Plattformen) wird im gemeinsamen Projektvorgehen geplant.