GBFS shows up in almost every shared mobility integration conversation, and almost as often, in a slightly wrong description of what it actually is. It’s not a data product, not a single file, and not exclusive to bikes anymore despite the name. It’s an open specification, and understanding the specification, not just knowing the acronym, is what separates a clean integration from a monthly feed-parsing headache.
Here’s what GBFS data actually is, what’s inside a feed, how to analyze it without the common pitfalls, and how Myles, SWITCH’s AI agent for mobility and logistics (getswitch.io) ingests it.
What GBFS actually is
GBFS, the General Bikeshare Feed Specification, is an open data standard maintained by MobilityData that defines how shared mobility operators publish real-time information about vehicle and station availability. It originated with bikeshare (the name is a holdover from NABSA, the North American Bikeshare Association, which co-created it), and has since broadened to cover scooters, mopeds, and shared cars. Most operators now publishing under GBFS run mixed or non-bike fleets.
The point of GBFS isn’t to give any one company a data advantage. It’s an open, machine-readable format so that trip planners, city dashboards, and third-party apps can show real-time availability without every consumer negotiating a custom integration with every operator.
What’s inside a GBFS feed
A GBFS feed is a set of linked JSON files, not one document. The core ones you’ll actually work with are system_information (metadata about the operator: name, timezone, operating region), vehicle_types (what kinds of vehicles the system operates and their attributes), station_information and station_status for station-based systems (station locations and real-time capacity), free_bike_status for free-floating systems (individual vehicle locations not tied to a fixed station), and system_pricing_plans (fare and pricing structure, when published).
A single operator publishes some or all of these depending on whether they run station-based, free-floating, or a hybrid system. That’s the first thing to check before building against a feed, since a station-based parser will silently return nothing useful against a free-floating feed.
How to analyze GBFS data without the common traps
Validate against the spec before trusting the data. Not every published feed is fully spec-compliant: fields go missing, timestamps drift out of the required format, so structure needs checking before any analysis logic runs on top of it. Check feed freshness, not just presence. A feed can be reachable and stale at the same time, since an operator’s backend can stop updating vehicle status while the URL keeps serving the last-known snapshot, so track the feed’s last-updated timestamp, not just whether the request succeeds. Normalize before joining across operators. Field naming and units are consistent within the spec, but operational conventions, how “available” is defined, how quickly a vehicle drops off after a trip starts, vary enough between operators that a straight join across feeds needs normalization first. And pair it with context, not just itself. Raw availability data tells you what’s parked where. It doesn’t tell you why, and that requires joining it against demand, weather, or event data, a separate step GBFS alone doesn’t cover.
GBFS vs MDS: a quick distinction
GBFS is built for real-time availability, consumed mainly by trip planners, apps, and analytics tools. MDS (Mobility Data Specification) is built for cities managing permitted operators: trip-level reporting, compliance, and policy enforcement, not real-time display. They solve adjacent but different problems, and a full comparison is covered in our GBFS vs. MDS breakdown.
How SWITCH uses GBFS data
GBFS feeds are one input among several in SWITCH’s data layer, which ingests 4,002 live mobility feeds across roughly 987 cities, validated, normalized, and joined against fleet telemetry and context data before Myles uses it to answer an operational question. The validation and freshness-checking steps described above aren’t optional extras. They’re what makes a GBFS feed usable for forecasting rather than just a live map.
Key takeaways
- GBFS is an open standard for real-time shared mobility availability, not exclusive to bikes despite the name, and not a single file but a linked set of them.
- Which files a feed publishes depends on whether the system is station-based, free-floating, or hybrid. Check that before building against it.
- Analyzing GBFS well means validating spec compliance, checking freshness rather than just reachability, and normalizing before joining across operators.
- GBFS covers real-time availability; MDS covers city-side permitting and compliance. Different problems, not competing standards.
Want to see GBFS and your own fleet data analyzed together, not just displayed? Try Myles free for 14 days.
