GBFS: the feed format that makes bike share findable

A uniform format for vehicle availability

GBFS, the General Bikeshare Feed Specification, is described as the open data standard for shared mobility, and its purpose is narrow and practical: make real-time data feeds in a uniform format publicly available online, with an emphasis on findability. The problem it solves is not that operators lack data, they publish plenty of it, but that each one publishes it differently. A consumer that wants to show every bike share in a city normally faces a separate integration per operator, with a separate URL discovery step, a separate payload shape and a separate update cadence. GBFS replaces that with a shared shape and a shared discovery convention, which is why the standard describes itself as making feeds findable rather than merely uniform. The audience is two-sided. Producers are operators of bike share, scooter share and car share systems who want their vehicles to show up in consumer apps without negotiating a private integration, and consumers are application developers and map products who want one parser for the whole city.

Read-only, and no personal data by design

Two constraints define the scope, and both are stated in the specification rather than implied. The first is direction: GBFS is intended as a specification for real-time, read-only data, and any data being written back into individual shared mobility systems is excluded from the spec. That is why the specification is usable as a public document at all, because it does not touch the transaction path. The second is privacy: GBFS is intended to make information publicly available online, therefore information that is personally identifiable is not currently and will not become part of the core specification. That is a stronger statement than a current practice, it is a commitment about the direction of the standard. The two design concepts behind it are equally simple: provide the status of the system at this moment, and do not provide information whose primary purpose is historical. A consumer that wants trip history, therefore, is looking for data this standard does not intend to carry.

Becoming part of the spec takes a producer and a consumer

The governance mechanics are the part of this repository that is most unusual, and they are specified with unusual precision. Anyone can raise an issue, and anyone can open a pull request, provided it lines up with the Guiding Principles. A discussion on a pull request must run for a minimum of 7 calendar days, votes then stay open for a total of 10 calendar days and anyone can vote. A successful vote needs at least 3 votes, not counting the pull request author, and it must include a vote from a GBFS producer and a vote from a GBFS consumer. That dual requirement is the mechanism that keeps the standard honest on both sides: a change that only operators want, or that only app developers want, cannot pass. The README points to a real pull request as an example of governance in action and to `governance.md` for the full process, and notes that MobilityData is happy to help people who want to open a pull request but do not know how.

v3.0 is current, v3.1-RC3 is waiting in the wings

The version table in the README is the practical reference for anyone integrating a feed, and it distinguishes three states. The current version is v3.0, a MAJOR release from April 11, 2024, with a JSON schema published alongside it and an upgrade article linked. Below it sits v3.1-RC3, a MINOR release candidate from May 26, 2026, marked ready for implementation, and the README explains the rule that governs it: release candidates receive current version status when they have been fully implemented in public feeds. That is a deliberate stability guarantee for consumers, since a release candidate only becomes the recommended version once operators are actually serving it. Older versions are given two further statuses, Supported, meaning they may be patched to correct bugs or vulnerabilities but will not receive new features, and Deprecated, meaning they are not patched and their use should be discontinued. So an integrator can read the table and know which version to target and how long it will keep working.

The specification, the schemas and the catalog are separate

The repository layout shows that the artefacts of this project are deliberately split. The specification document itself is `gbfs.md` at the root, with `governance.md` next to it describing how the change process works. The JSON schemas live in a separate repository, gbfs-json-schema, with a versioned branch per release, so a consumer can pin validation to the version it actually speaks. The list of systems implementing GBFS is kept as `systems.csv` in this repository, which is the practical answer to the findability problem, since a client still has to know where each operator's feed lives. `scripts/` and `images/` hold the supporting tooling and diagrams. The specification is therefore not the whole deliverable, it is one artefact in a set, and an integrator needs at least the spec text, the schema for the version it targets and the catalog of feeds.

Consensus has a price, and the community has noticed

The honest limitation is speed. A change needs seven days of discussion, ten days of voting, at least three outside votes and a producer plus a consumer, so a specification change moves on a scale of weeks rather than days. For a standard meant to describe a fast-moving industry, that is a deliberate trade, and the README makes the intent explicit: the specification is not fixed or unchangeable, and as the shared mobility industry evolves it is expected that the specification will be extended by the community to include new features and capabilities over time. The cost lands on whoever needs a field that does not exist yet. A product team that needs yesterday's data will either wait for a release candidate to work its way through the process and into public feeds, or maintain its own extension outside the standard, which reintroduces the fragmentation the standard exists to remove. The other limitation is scope: because the specification is about the status of the system at this moment, a consumer that needs historical analysis, journey planning with past trips or anything transactional has to look elsewhere.

Licence, hosting and who is in charge

The provenance explains the shape of the governance. GBFS was created in 2014 by Mitch Vars with collaboration from public, private sector and non-profit shared mobility system owners and operators, application developers and technology vendors, and significant work on v1.0 was done on behalf of Motivate International LLC, now Lyft. The North American Bikeshare Association's endorsement, support and hosting were key to its success from 2015, and in 2019 NABSA chose MobilityData to govern and facilitate the improvement of GBFS. MobilityData now hosts the GBFS Resource Center at gbfs.org and a public Slack channel, and the project describes itself as an open source project under a consensus-based governance model that is not owned by any one person or organization. On licensing, the licence field on the repository points to a LICENSE file in the repository root rather than naming a standard identifier, so the terms are the ones written in that file and an integrator embedding GBFS definitions in a product should read it directly. On maintenance, the tree is active: the last push was on 2026-10-19 and the newest artefact is the v3.1-RC3 release candidate from 2026-05-26.

Editorial conclusion

GBFS fits anyone building a shared mobility app or map who needs one parser instead of one per operator, and fits operators who want their feed to appear in third-party clients without bespoke integrations. It does not fit a product that needs trip histories, booking or payment, since the specification is explicitly read-only and excludes anything written back into operator systems. Before adopting it, check which version your consumer ecosystem supports, since v3.0 is the current version while v3.1-RC3 only becomes current once it is implemented in public feeds, and read the LICENSE file in the repository root, since the licence field on the repository points there instead of naming a standard identifier.

Frequently asked questions

Official sources

1. Issues
2. MobilityData/gbfs on GitHub
3. Project website
4. README
5. Releases