↑ Aufzugsstatus API
API v1 · betrieben von plötzlich querschnitt

Live-Aufzugsstörungen an deutschen Bahnhöfen.

Ein aggregierter, frei nutzbarer JSON-Feed aus den Störungsmelde-Systemen von Deutscher Bahn, HVV, BVG, KVB, MVG, VGF und weiteren. Kein API-Key, kein Login, kein Tracking.

Alle Quellen werden alle 5 Minuten neu abgefragt
curl · in deiner Nähe
curl "https://aufzuege.barrierefrei-unterwegs.info/stations/near\
?lat=53.55&lon=9.99&radius_km=5"
01 — Woher die Daten kommen

Datenquellen

Neun offizielle und community-basierte Live-Feeds werden serverseitig zusammengeführt, dedupliziert und normalisiert. Bei überlappenden Meldungen (z. B. HVV und brokenlifts für dieselben Hamburger Aufzüge) gewinnt die primäre Quelle.

DBFaSta
BVGBerlin
HVVHamburg
KVBKöln
MVGMünchen
VGFFrankfurt
BOGBochum
CCbrokenlifts.org

Für die Schweiz kommt seit Version 2.3 ein Live-Aufzugsstatus dazu: SBB veröffentlicht Aufzugsstörungen im SIRI-SX-„unplanned"-Feed auf opentransportdata.swiss, dort filtert der Server auf AlertCause = liftFailure. Jede Störung enthält die konkrete OSM-Node-ID des betroffenen Aufzugs, Standort, mehrsprachigen Fahrgast-Text und die geplante Dauer. Zusätzlich weiterhin: statische Rollstuhl-Zugänglichkeit pro Bahnhof (autonom / mit Assistenz / nicht barrierefrei) aus der BehiG-Bestandsaufnahme der SBB (Dataset bfr-rollstuhl, täglich aktualisiert). Aufzugsstandorte kommen aus OpenStreetMap.

SBBSIRI-SX Live (CH)
SBBBehiG (CH)
02 — Endpoints

Sechs Wege in die Daten

Alle Antworten sind JSON, alle Requests sind GET. Base-URL: https://aufzuege.barrierefrei-unterwegs.info.

GET /stations/near

Bahnhöfe im Umkreis eines Punktes, sortiert nach Entfernung. Der Rückgabewert ist bereits pro Bahnhof aggregiert (Anzahl aller Aufzüge, davon defekt).

Query-Parameter
NameTypBeschreibung
latfloatPflichtBreitengrad (WGS84)
lonfloatPflichtLängengrad (WGS84)
radius_kmfloatoptionalSuchradius in Kilometern. Standard 25, Maximum 100.
limitintoptionalMaximale Trefferzahl. Standard 20, Maximum 200.
Beispiel
Request
GET /stations/near?lat=53.55&lon=9.99&radius_km=25&limit=5
Response · 200 OK
[
  {
    "name": "Hamburg Hbf",
    "station_number": 1734,
    "lifts": 12,
    "defekt": 2,
    "distance_km": 0.4,
    "lat": 53.552,
    "lon": 10.006
  }
]
GET /stations/search

Bundesweite Bahnhofssuche per Namensteil. Für Autocomplete gedacht — Antwort kommt in unter 100 ms.

Query-Parameter
qstringPflichtMindestens zwei Zeichen. Substring-Suche, case-insensitive.
Beispiel
Request
GET /stations/search?q=pinneberg
Response · 200 OK
[
  {
    "name": "Pinneberg",
    "station_number": 4859,
    "lifts": 3,
    "defekt": 1
  }
]
GET /lifts

Detaildaten aller Aufzüge zu einem Bahnhof — inkl. Bezeichnung, letztem Status, Klartext-Störungsgrund und dem last_seen-Zeitstempel für die Datenfrische.

Query-Parameter
qstringPflichtBahnhofsname (exakt oder Substring).
limitintoptionalStandard 50, Maximum 200.
Beispiel
Request
GET /lifts?q=Pinneberg
Response · 200 OK (Auszug)
[
  {
    "id": "fasta:12345",
    "source": "fasta",
    "type": "ELEVATOR",
    "station_number": 4859,
    "station_name": "Pinneberg",
    "description": "Aufzug zu Bahnsteig 2/3",
    "operator": "DB Station&Service",
    "state": "INACTIVE",
    "state_explanation": "technische Störung",
    "state_since": "2026-08-30T09:12:00+02:00",
    "last_seen": "2026-08-30T14:35:00+02:00",
    "lat": 53.6621,
    "lon": 9.7897
  }
]
GET /stations/access

Statische Rollstuhl-Zugänglichkeit eines Schweizer Bahnhofs aus der offiziellen BehiG-Bestandsaufnahme der SBB (Dataset bfr-rollstuhl, täglich aktualisiert). Antwortet nur für CH-Bahnhöfe; für DE-/AT-Stationen kommt 404.

Query-Parameter
namestringoptionalBahnhofsname (exakt case-insensitive, sonst LIKE-Suche).
didokintoptional7-stellige DIDOK-ID. Wenn gesetzt, hat sie Vorrang.

Mindestens name oder didok muss gesetzt sein.

Beispiel
Request
GET /stations/access?name=Z%C3%BCrich%20HB
Response · 200 OK
{
  "level": "autonom",
  "kanten_gesamt": 25,
  "kanten_autonom": 22,
  "kanten_assistenz": 0,
  "valid_from": "02.09.2026",
  "valid_to": "02.10.2026"
}

level ist einer von autonom, mit_assistenz, nicht_barrierefrei. Die Kanten-Zähler geben an, wie viele Bahnsteig-Kanten pro Bahnhof welchen Level tragen — nützlich, wenn ein Bahnhof gemischt ist.

GET /stations/liftstatus

Aktive Aufzugsstörungen an einem Schweizer Bahnhof aus dem SBB-SIRI-SX-Feed (opentransportdata.swiss). Antwortet eine Liste, weil ein Bahnhof mehrere defekte Aufzüge haben kann (z. B. Zürich HB). Leere Liste bei DE-/AT-Bahnhöfen oder wenn kein Ausfall gemeldet ist — kein 404, „ohne Störung" ≠ „unbekannt".

Query-Parameter
namestringoptionalBahnhofsname (case-insensitive, Substring-Match).
osm_node_idintoptionalOSM-Node-ID eines konkreten Aufzugs — filtert auf genau diesen Lift.

Mindestens name oder osm_node_id muss gesetzt sein.

Beispiel
Request
GET /stations/liftstatus?name=Kilchberg%20ZH
Response · 200 OK
[
  {
    "situation_number": "ch:1:sstid:100001:…-TT1056445",
    "station_name": "Kilchberg ZH",
    "facility_name": "Gleis 1, Zugang Bahnhofstrasse - Überführung",
    "osm_node_id": 12157691830,
    "lat": 47.32420273,
    "lon": 8.548055869,
    "summary": "Der stufenfreie Zugang zum Bahnhof Kilchberg ZH ist …",
    "recommendation": "Contact Center Handicap: Tel. 0800 007 102 …",
    "duration": "Die Einschränkung dauert bis zirka 03.09.2026, 22:00.",
    "since": "2026-07-26T19:58:00Z",
    "valid_to": "2026-09-03T20:00:00Z"
  }
]

osm_node_id ist der Schlüssel zum deterministischen Match mit dem /lifts-Endpunkt (dort steckt die ID in source_id). Feld-Fallbacks: lat/lon können null sein, wenn der Feed für einen Bahnhof keine Koordinaten liefert — dann Bahnhof-Koordinaten aus /lifts als Fallback verwenden.

GET /lifts/failures

Alle aktuell aktiven CH-Aufzugsstörungen als flache Liste — gedacht für Kartenlayer, die pro OSM-Aufzug prüfen wollen, ob er in einer Störung steht. Kleine Response (typisch < 30 Einträge), empfohlener Client-Cache: 5 Minuten (deckt sich mit dem Poll-Intervall des Servers).

Beispiel
Request
GET /lifts/failures
Response · 200 OK
[
  { "osm_node_id": 12157691830,
    "station_name": "Kilchberg ZH",
    "facility_name": "Gleis 1, …",
    "summary": "…", "duration": "…" },
  { "osm_node_id": 8085496702,
    "station_name": "Zürich Altstetten",
    "facility_name": "Gleis 3/4", … }
]

Objekt-Schema identisch zu /stations/liftstatus. Idee für die App: einmal beim Karten-Start holen, dann jeden Aufzug-Marker rot färben, dessen osm_node_id in der Liste steht.

03 — Datenqualität

Wenn keine Daten kommen, sagen wir das.

Jeder Aufzug trägt ein last_seen-Feld — den Zeitpunkt der letzten erfolgreichen Abfrage seines Quell-Feeds. Aus dem Alter dieses Zeitstempels ergibt sich die einzig ehrliche Interpretation des Status:

≤ 15 Min alt
In Betrieb
Daten sind frisch, state gilt unverändert.
15–60 Min alt
Status unklar
Auch bei state = ACTIVE sollte hier „unklar" gezeigt werden — der Feed hat sich nur nicht mehr gemeldet.
> 60 Min alt
Feed ist stumm
Quelle ist ausgefallen. Nicht die Aufzüge, sondern die Datenversorgung. Alternative Route planen oder alte Werte ignorieren.

Diese Logik ist in der iOS- und Android-App direkt sichtbar. Wer die API selbst nutzt, sollte sie mitimplementieren — sonst zeigt die App im Zweifel „alles gut" auf Basis mehrere Stunden alter Daten.

04 — Für LLMs

MCP-Server für Claude, ChatGPT & Co.

Ein Model-Context-Protocol-Endpunkt stellt dieselben Daten als Tool für Sprachmodelle bereit. Der Assistent bekommt echte Live-Störungen zurück — nicht die trainings-alte Vermutung, dass „Bahnhof X einen Aufzug hat".

Endpoint

Streamable HTTP unter https://aufzuege.barrierefrei-unterwegs.info/mcp — read-only, ohne Auth. In Claude/ChatGPT als Custom Connector einbinden. Beispiel-Prompt:

Prompt
„Kann ich morgen früh mit dem Rollstuhl von Pinneberg
nach Berlin Ostkreuz umsteigefrei fahren? Bitte alle
Aufzüge auf der Route auf aktuelle Störungen prüfen."
05 — Nutzung

Fair Use

Frei nutzbar heißt frei nutzbar — nicht rücksichtslos. Ein paar Regeln, damit der Service für alle stabil bleibt: