GET/api/v1/trips

Fahrten

Fahrten als Fahrplan-Vorlagen inklusive Halte-Zeiten und Verkehrstagen — nicht als Einzeltermine. Konkrete Termine ergeben sich aus serviceDays.

Wofür

Das Soll-Angebot: welche Fahrt an welchen Wochentagen zu welcher Zeit welche Halte bedient. Grundlage für Umlaufbildung und für die Frage, wie viel Fahrzeugzeit ein Tag überhaupt braucht.

Anfrage

Erfordert das Recht read:schedule.

AnfrageShell

curl -sS \
  -H "Authorization: Bearer rb_live_…" \
  "https://rufbusle.de/api/v1/trips"

Query-Parameter

limit: Seitengröße, 1–200. Ohne Angabe 50.
cursor: Wert aus nextCursor der vorigen Seite.

Antwort

Seitenweise: data mit den Einträgen, nextCursor für die Folgeseite.

BeispielantwortJSON

{
  "data": [
    {
      "id": "trp_9Vc4mQ",
      "lineId": "lin_3Nb8pZ",
      "headsign": "Musterstadt Bahnhof",
      "directionId": 0,
      "isFlex": false,
      "blockId": null,
      "serviceDays": {
        "monday": true,
        "tuesday": true,
        "wednesday": true,
        "thursday": true,
        "friday": true,
        "saturday": false,
        "sunday": false,
        "startDate": "2026-01-01",
        "endDate": "2026-12-31"
      },
      "stopTimes": [
        {
          "stopId": "stp_7Kq2vX",
          "sequence": 1,
          "arrivalTime": "08:15",
          "departureTime": "08:15",
          "pickupWindowStart": "08:15",
          "pickupWindowEnd": "08:15"
        }
      ]
    }
  ],
  "nextCursor": "bkg_5Rt8wY"
}

Beispielwerte, keine echten Daten. Unbekannte Felder bitte ignorieren — es können jederzeit welche hinzukommen.

Felder je Eintrag (Trip)

Die Hülle mit data und nextCursor ist bei allen Listen gleich; hier stehen die Felder eines einzelnen Eintrags.

Feld	Typ	Beschreibung
`id`	`string`	Referenz für tripId einer Buchung.
`lineId`	`string`	Linie, zu der die Fahrt gehört.
`headsign`	`string \| null`	Zielbeschilderung, falls gepflegt.
`directionId`	`integer`	Fahrtrichtung, 0 oder 1 (GTFS direction_id).
`isFlex`	`boolean`	Bedarfsfahrt mit Abholfenster statt fester Abfahrtszeit.
`blockId`	`string \| null`	GTFS block_id — Umlaufbindung, falls gepflegt.
`serviceDays`	`object`	Wochentage und Zeitraum, an denen diese Fahrt stattfindet.
`monday`	`boolean`	Verkehrt montags.
`tuesday`	`boolean`	Verkehrt dienstags.
`wednesday`	`boolean`	Verkehrt mittwochs.
`thursday`	`boolean`	Verkehrt donnerstags.
`friday`	`boolean`	Verkehrt freitags.
`saturday`	`boolean`	Verkehrt samstags.
`sunday`	`boolean`	Verkehrt sonntags.
`startDate`	`string`	Erster Geltungstag (YYYY-MM-DD).
`endDate`	`string`	Letzter Geltungstag (YYYY-MM-DD).
`stopTimes`	`object[]`	Halte der Fahrt, aufsteigend nach sequence.
`stopId`	`string \| null`	Verweis auf einen Halt; null bei reiner Zonenbedienung.
`sequence`	`integer`	Position innerhalb der Fahrt, ab 1.
`arrivalTime`	`string`	Planmäßige Ankunft, Ortszeit „HH:MM".
`departureTime`	`string`	Planmäßige Abfahrt, Ortszeit „HH:MM".
`pickupWindowStart`	`string \| null`	Beginn des Abholfensters bei Flex-Fahrten; sonst null.
`pickupWindowEnd`	`string \| null`	Ende des Abholfensters bei Flex-Fahrten; sonst null.

Worauf zu achten ist

Die Punkte, an denen Integrationen erfahrungsgemäß hängen bleiben.

Eine Fahrt ist eine Vorlage, kein Termin. Die tatsächlichen Tage ergeben sich aus serviceDays (Wochentage plus Gültigkeitszeitraum) — eine Buchung nennt mit rideDate den konkreten Tag.
blockId trägt die Umlaufbindung aus GTFS, sofern sie gepflegt ist. Ist sie leer, gibt es in RufBusle keine hinterlegte Umlaufzuordnung — ein leeres Feld ist keine Aussage über den Betrieb.
Bei Flex-Fahrten (isFlex: true) sind arrivalTime/departureTime nachrangig; maßgeblich ist das Zeitfenster pickupWindowStart–pickupWindowEnd.

Wofür#

Anfrage#

Query-Parameter

Antwort#

Felder je Eintrag (Trip)#

Worauf zu achten ist#

Wofür

Anfrage

Antwort

Felder je Eintrag (Trip)

Worauf zu achten ist