General Bikeshare Feed Specification

Documentation for the General Bikeshare Feed Specification, a standardized data feed for shared mobility system availability.

Please note that GBFS is now hosted at github.com/MobilityData/gbfs.

What is GBFS?
How to Participate
Current Version
Guiding Principles
Specification Versioning
Systems Catalog - Systems Implementing GBFS
GBFS JSON Schemas
GBFS and Other Shared Mobility Resources
Relationship Between GBFS and MDS

What is GBFS?

The General Bikeshare Feed Specification, known as GBFS, is the open data standard for shared mobility. GBFS makes real-time data feeds in a uniform format publicly available online, with an emphasis on findability. 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.

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. Michael Frumin, Jesse Chan-Norris and others made significant contributions of time and expertise toward the development of v1.0 on behalf of Motivate International LLC (now Lyft). The North American Bikeshare Association’s endorsement, support, and hosting was key to its success starting in 2015. In 2019, NABSA chose MobilityData to govern and facilitate the improvement of GBFS. MobilityData hosts a GBFS Resource Center and a public GBFS Slack channel - you are welcome to contact us there or at sharedmobility@mobilitydata.org with questions.

GBFS is intended as a specification for real-time, read-only data - any data being written back into individual shared mobility systems are excluded from this spec.

The specification has been designed with the following concepts in mind:

Provide the status of the system at this moment
Do not provide information whose primary purpose is historical

The data in the specification contained in this document is intended for consumption by clients intending to provide real-time (or semi-real-time) transit advice and is designed as such.

How to Participate

GBFS is an open source project developed under a consensus-based governance model. Contributors come from across the shared mobility industry, public sector, civic technology and elsewhere. GBFS is not owned by any one person or organization. The specification is not fixed or unchangeable. As the shared mobility industry evolves, it is expected that the specification will be extended by the GBFS community to include new features and capabilities over time. <br/><br> Comments or questions can be addressed to the community by opening an issue. Proposals for changes or additions to the specification can be made through pull requests. Questions can also be addressed to the community via the public GBFS Slack channel or to the shared mobility staff at MobilityData: sharedmobility@mobilitydata.org. If you are new to engaging with the community on this repository, firstly welcome! Here is a brief overview of how to contribute to the specification:

Anyone can raise an issue.
Anyone can open a pull request - make sure PRs in line with our Guiding Principles.
If you are wanting to open a pull request but don't know how, MobiilityData is happy to help. Get in touch at sharedmobility@mobilitydata.org.
Discussions on pull requests must be a minimum of 7 calendar days.
Votes are open for a total of 10 calendar days, anyone can vote.
A successful vote must have at least 3 votes, not including the pull request author.
A successful vote must include a vote from a GBFS producer and a GBFS consumer.

Find a real-world example of the governance in action here. For a more in depth look at the change and contribution process, go to governance.md.

Project Roadmap

MobiltyData has compiled a project roadmap with a list of major features, changes and other work coming up in the near future.

Current Version (Recommended)

| Version | Type | Release Date | Status | JSON Schema | Release Notes | |:---:|:---:|---|---|---| ---| | v3.0 | MAJOR | April 11, 2024 | :white_check_mark: Current Version | v3.0 Schema | v3.0 Article |

Upcoming MAJOR Version

| Version | Type | Release Target | Status | |------------------------------------|:---:|---|---| | No current upcoming major versions | | | |

Release Candidates

Release Candidates will receive Current Version status when they have been fully implemented in public feeds.

| Version | Type | Release Date | Status | JSON Schema | Release Notes | |:---:|:-----:|----------------|----------------------------|----------------------------------------------------------------------------------------|---------------------| | v3.1-RC2 | MINOR | May 28, 2025 | :white_check_mark: Ready for implementation | coming soon | v3.1-RC2 Release Notes | | v3.1-RC | MINOR | May 22, 2024 | :white_check_mark: Ready for implementation | v3.1-RC Schema | v3.1-RC Release Notes |

Past Version Releases

Past versions with Supported status MAY be patched to correct bugs or vulnerabilities but new features will not be introduced.<br /> Past versions with Deprecated status will not be patched and their use SHOULD be discontinued.

| Version | Type | Release Date | Status | JSON Schema | Release Notes | |:---:|:---:|---|---|---|---| | v2.3 | MINOR | April 5, 2022 | :white_check_mark: Supported | v2.3 Schema | v2.3 Release Notes | | v2.2 | MINOR | March 19, 2021 |:white_check_mark: Supported | v2.2 Schema| v2.2 Article | v2.1 | MINOR | March 18, 2021 |:white_check_mark: Supported | v2.1 Schema| v2.1 Article | v2.0 | MAJOR | March 16, 2020 | :white_check_mark: Supported | v2.0 Schema | v2.0 Article | | v1.1 | MINOR | March 16, 2020 |:x: Deprecated | v1.1 Schema | | | v1.0 | MAJOR | Prior to October 2019 | :x: Deprecated | v1.0 Schema| |

Full Version History

The complete GBFS version history is available in the Release Notes.

Specification Versioning

To enable the evolution of GBFS, including changes that would otherwise break backwards-compatibility with consuming applications, GBFS uses semantic versioning. Semantic versions are established by a git tag in the form of vX.Y where X.Y is the version name. A whole integer increase is used for breaking changes (MAJOR changes). A decimal increase is used for non-breaking changes (MINOR changes or patches). MINOR versions may introduce new features as long as those changes are OPTIONAL and do not break backwards compatibility.

Examples of breaking changes include:

Changes to requirements, like adding or removing a REQUIRED endpoint or field, or changing an OPTIONAL endpoint or field to REQUIRED.
Changing the data type or semantics of an existing field.

Examples of non-breaking changes include:

Adding an OPTIONAL endpoint or field
Adding new enum values
Modifying documentation or specification language in a way that clarifies semantics or recommended practices

Release Deprecation

GBFS documentation will include a list of current and supported MAJOR and MINOR versions. Supporte

Gbfs

Install / Use

README