GBFS 3.0-Feeds

GBFS 3.0 ist die Spezifikation, gegen die der MobilityData-Validator nun prueft, und die meisten neuen Tier-1-Stadtgenehmigungen verweisen explizit darauf. Levy Fleets veroeffentlicht beide Feeds parallel:

Feed-Stamm -- gbfs.json

curl https://fleets.levyelectric.com/api/gbfs/v3/<subaccountId>/gbfs.json

Liefert das Discovery-Dokument mit Pfaden zu jeder anderen Feed-Datei:

{
  "last_updated": "2026-05-18T12:00:00Z",
  "ttl": 60,
  "version": "3.0",
  "data": {
    "feeds": [
      { "name": "manifest", "url": "..." },
      { "name": "system_information", "url": "..." },
      { "name": "vehicle_types", "url": "..." },
      { "name": "vehicle_status", "url": "..." },
      { "name": "station_information", "url": "..." },
      { "name": "station_status", "url": "..." },
      { "name": "system_regions", "url": "..." },
      { "name": "system_pricing_plans", "url": "..." },
      { "name": "geofencing_zones", "url": "..." },
      { "name": "system_alerts", "url": "..." }
    ]
  }
}

Neuerungen gegenueber GBFS 2.x

manifest.json

Neu in 3.0. Deklariert Sprachen, die GBFS-Version und das Auth-Schema (falls vorhanden). Levys Manifest wird aus der default_language des Subaccounts plus allen Sprachen mit mindestens einem lokalisierten Feld generiert.

{
  "last_updated": "2026-05-18T12:00:00Z",
  "ttl": 60,
  "version": "3.0",
  "data": {
    "datasets": [
      {
        "system_id": "levy-<subaccountId>",
        "versions": [
          { "version": "3.0", "url": ".../v3/<subaccountId>/gbfs.json" },
          { "version": "2.3", "url": ".../<subaccountId>/gbfs.json" }
        ]
      }
    ]
  }
}

Das Manifest teilt Discovery-Aggregatoren (MobilityData, Transit-Apps) mit, dass 2.x und 3.0 fuer dasselbe System verfuegbar sind.

vehicle_status.json

Ersetzt free_bike_status.json. Jede Zeile traegt eine vehicle_type_id, die auf vehicle_types.json verweist:

{
  "version": "3.0",
  "last_updated": "2026-05-18T12:00:00Z",
  "ttl": 60,
  "data": {
    "vehicles": [
      {
        "vehicle_id": "abc123",
        "vehicle_type_id": "scooter_standard",
        "lat": 40.0149,
        "lon": -105.2705,
        "current_range_meters": 18000,
        "is_reserved": false,
        "is_disabled": false,
        "last_reported": "2026-05-18T11:59:47Z"
      }
    ]
  }
}

Die vehicle_type_id des Fahrzeugs ergibt sich aus vehicles.model_id -> vehicle_models.gbfs_type_id. Letztere unter Einstellungen -> Fahrzeugmodelle beim Import neuer SKUs setzen.

geofencing_zones.json -- Betreiber- + Policy-Zonen zusammengefuehrt

Dies ist die Datei, in der Stadt-Compliance im oeffentlichen Feed sichtbar wird. Sie enthaelt jede Betreiberzone (Parken, No-Parking, Slow, No-Go, Ride-Zonen) plus jede aktive policy_geofences-Zeile fuer den Subaccount. Jedes Feature emittiert die richtige vehicle_type_id pro Regel pro MDS-Policy.

Die Reihenfolge zaehlt: Features sind nach Prioritaet absteigend sortiert, sodass Verbraucher, die das "erste Match" waehlen, die strengste Regel bekommen. Siehe Prioritaet gestapelter Geofences.

{
  "version": "3.0",
  "last_updated": "2026-05-18T12:00:00Z",
  "ttl": 60,
  "data": {
    "geofencing_zones": {
      "type": "FeatureCollection",
      "features": [
        {
          "type": "Feature",
          "properties": {
            "name": "Boulder Pearl Street No-Ride",
            "rules": [
              {
                "vehicle_type_ids": ["scooter_standard"],
                "ride_allowed": false,
                "ride_through_allowed": false
              }
            ],
            "priority": 950,
            "source": "city",
            "source_jurisdiction_id": "boulder-co"
          },
          "geometry": { "type": "Polygon", "coordinates": [ ... ] }
        }
      ]
    }
  }
}

Die priority-, source- und source_jurisdiction_id-Eigenschaften sind Levy-Erweiterungen ueber dem GBFS-Schema -- sie werden von Validatoren ignoriert und von Clients (einschliesslich unserer eigenen mobilen App) verarbeitet, die die Stack-Semantik verstehen.

system_regions.json

Neu in 3.0. Nuetzlich, wenn ein einzelner Subaccount in mehreren unterschiedlichen geografischen Regionen operiert (z.B. getrennte Campusse oder Stadtteile). Levy emittiert standardmaessig eine Region pro mds_jurisdictions-Zeile; Namen und Sprachlabels koennen unter Compliance -> Zustaendigkeiten -> Bearbeiten -> Regionen angepasst werden.

system_alerts.json

Traegt vom Betreiber veroeffentlichte Warnungen (geplante Ausfaelle, besondere Ereignisse, Wetterbeschraenkungen). Wird derzeit von der Einstellungen -> Warnungen-UI gesteuert; an Subaccount gebunden, nicht pro Zustaendigkeit.

Caching

Wie der MDS-Feed werden GBFS 3.0-Endpunkte am Edge fuer 60 Sekunden gecacht (Cache-Control: public, s-maxage=60). Der ttl-Wert in jedem Datei-Payload entspricht dem Cache-Fenster.

Validator-Konfiguration

Nutzen Sie MobilityDatas gbfs-validator fuer End-to-End-Pruefungen:

gbfs-validator https://fleets.levyelectric.com/api/gbfs/v3/<subaccountId>/gbfs.json

Ein sauberer Lauf meldet Errors: 0, Warnings: 0. Haeufige Warnungen beim ersten Onboarding:

• vehicle_type_id fehlt bei einem Fahrzeug -- vehicle_models.gbfs_type_id fuer jedes Modell in Ihrer Flotte setzen.
• system_regions.json leer -- mindestens eine mds_jurisdictions-Zeile hinzufuegen oder die Datei aus gbfs.json entfernen, falls Sie nicht in mehreren Regionen operieren.
• pricing_plans fehlt -- mindestens eine Zeile in pricing_plans fuer den Subaccount setzen.

Wie v2 und v3 synchron bleiben

Beide Feeds lesen aus den gleichen Basis-Tabellen (vehicles, vehicle_models, zones, policy_geofences, stations, pricing_plans). Es gibt keinen separaten Schreibweg fuer v3, sodass eine Aenderung im Dashboard in beiden Feeds beim naechsten 60-Sekunden-Cache-Zyklus erscheint.

Die einzigen Dateien, die nur in v3 leben, sind manifest.json und system_regions.json. Den v3-Feed zu entfernen (falls eine Stadt nur v2.x benoetigt) bedeutet einfach, ihn nicht auf die /v3/-URL zu verweisen.

Was kommt als naechstes?

• Policy-Aufnahme von Staedten -- woher die in geofencing_zones.json eingemischten Policy-Geofences kommen.
• Prioritaet gestapelter Geofences -- die Prioritaetsleiter bei Zonenueberlappungen.
• MDS Provider-Einrichtung -- die signierten MDS-Endpunkte, die Staedte parallel zu GBFS verbrauchen.