gbfs
Documentation for the General Bikeshare Feed Specification, a standardized data feed for shared mobility system availability.
https://github.com/MobilityData/gbfs
Category: Consumption
Sub Category: Mobility and Transportation
Keywords
bike-share bike-sharing bikesharing carshare carsharing civic-tech gbfs gbfs-documentation mobility mobility-as-a-service mobilitydata open-data scooter-sharing shared-mobility urban-mobility
Keywords from Contributors
cities bike public-transport bikeshare mds gtfs-feed gtfs-validator gtfs-realtime transit-data scooters
Last synced: about 16 hours ago
JSON representation
Repository metadata
Documentation for the General Bikeshare Feed Specification, a standardized data feed for shared mobility system availability. Maintained by MobilityData
- Host: GitHub
- URL: https://github.com/MobilityData/gbfs
- Owner: MobilityData
- License: other
- Created: 2015-12-04T23:43:43.000Z (over 9 years ago)
- Default Branch: master
- Last Pushed: 2025-04-17T13:02:46.000Z (10 days ago)
- Last Synced: 2025-04-20T12:11:22.769Z (7 days ago)
- Topics: bike-share, bike-sharing, bikesharing, carshare, carsharing, civic-tech, gbfs, gbfs-documentation, mobility, mobility-as-a-service, mobilitydata, open-data, scooter-sharing, shared-mobility, urban-mobility
- Homepage: https://gbfs.org
- Size: 1.67 MB
- Stars: 827
- Watchers: 78
- Forks: 295
- Open Issues: 10
- Releases: 15
-
Metadata Files:
- Readme: README.md
- Governance: governance.md
README.md
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.
Table of Contents
- 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 [email protected] 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. 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: [email protected].
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 [email protected].
- 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 | ✅ 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-RC | MINOR | May 22, 2024 | ✅ 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.
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 | ✅ Supported | v2.3 Schema | v2.3 Release Notes |
v2.2 | MINOR | March 19, 2021 | ✅ Supported | v2.2 Schema | v2.2 Article |
v2.1 | MINOR | March 18, 2021 | ✅ Supported | v2.1 Schema | v2.1 Article |
v2.0 | MAJOR | March 16, 2020 | ✅ Supported | v2.0 Schema | v2.0 Article |
v1.1 | MINOR | March 16, 2020 | ❌ Deprecated | v1.1 Schema | |
v1.0 | MAJOR | Prior to October 2019 | ❌ 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. Supported versions SHALL NOT span more than two MAJOR versions. Past versions that are beyond the two most recent MAJOR versions will be deprecated 180 days after the latest MAJOR version becomes official.
Version Release Cycles
- See the Governance for Version Release Cycles.
Guiding Principles
To preserve the original vision of GBFS, the following guiding principles should be taken into consideration when proposing extensions to the spec:
-
GBFS is a specification for real-time or semi-real-time, read-only data.
The spec is not intended for historical or archival data such as trip records.
The spec is about public information intended for shared mobility users. -
GBFS is targeted at providing transit information to the shared mobility end user.
Its primary purpose is to power tools for riders that will make shared mobility more accessible to users. GBFS is about public information. Producers and owners of GBFS data should take licensing and discoverability into account when publishing GBFS feeds. -
Changes to the spec should be backwards-compatible, when possible.
Caution should be taken to avoid making changes to the spec that would render existing feeds invalid. -
Speculative features are discouraged.
Each new addition to the spec adds complexity. We want to avoid additions to the spec that do not provide additional value to the shared mobility end user.
Systems Catalog - Systems Implementing GBFS
There are hundreds of shared mobility systems publishing GBFS worldwide. This list contains all known systems publishing GBFS feeds and is maintained by the GBFS community. This is an incomplete list. If you have or are aware of a system that doesn’t appear on the list please add it.
If you would like to add a system, please fork this repository and submit a Pull Request. To open a Pull Request, please do the following:
- Create an account on GitHub if you do not already have one
- Fork this repository
- Create a new branch, and
- Propose your changes by opening a new pull request
Please keep this list alphabetized by country and system name. Alternatively, fill out this contribution form for a Github-less contribution.
Field Name | REQUIRED | Definition |
---|---|---|
Country Code | REQUIRED | ISO 3166-1 alpha-2 code designating the country where the system is located. For a list of valid codes see here. |
Name | REQUIRED | Name of the mobility system. This MUST match the name field in system_information.json |
Location | REQUIRED | Primary city in which the system is located, followed by the 2-letter state code for US systems. The location name SHOULD be in English if the location has an English name (eg: Brussels ). |
System ID | REQUIRED | ID for the system. This MUST match the system_id field in system_information.json . |
URL | REQUIRED | URL for the system from the url field in system_information.json . If the url field is not included in system_information.json this SHOULD be the primary URL for the system operator. |
Auto-Discovery URL | REQUIRED | URL for the system's gbfs.json auto-discovery file. |
Supported Versions | REQUIRED | List of GBFS version(s) under which the feed is published. Multiple values are separated by a semi-colon surrounded with 1 space on each side for readability (" ; "). |
Authentication Info URL | Conditionally REQUIRED | If authentication is required, this MUST contain a URL to a human-readable page describing how the authentication should be performed and how credentials can be created. |
Authentication Type | Conditionally REQUIRED | If authentication is required, the type MUST be included. The Authentication Type field defines the type of authentication required to access the feed. Valid values for this field are: 0 or (empty) - No authentication required.1 - The authentication requires an API key, which should be passed as value of the parameter Authentication Parameter Name in the URL. Please visit the URL in Authentication Info URL for more information. 2 - The authentication requires an HTTP header, which should be passed as the value of the header Authentication Parameter Name in the HTTP request. When not provided, the authentication type is assumed to be 0. |
Authentication Parameter Name | Conditionally REQUIRED | If authentication is required, the parameter name MUST be included. The Authentication Parameter Name field defines the name of the parameter to pass in the URL or header to provide the authentication credentials. This field is required for Authentication Type=1 and Authentication Type=2 . In case of multiple parameters, use the pipe character to separate them (| ). |
GBFS JSON Schemas
Complete JSON schemas for each version of GBFS can be found here.
GBFS and Other Shared Mobility Resources
Including APIs, datasets, validators, research, and software can be found here.
Relationship Between GBFS and MDS
There are many similarities between GBFS and MDS (Mobility Data Specification), however, their intended use cases are different. GBFS is a real-time or near real-time specification for public data primarily intended to provide transit advice through consumer-facing applications. MDS is not public data and is intended for use only by mobility regulators. Publishing a public GBFS feed is a requirement of all MDS compatible Provider APIs.
Copyright
The copyright for GBFS is held by the MobilityData.
Owner metadata
- Name: MobilityData IO
- Login: MobilityData
- Email: [email protected]
- Kind: organization
- Description: Better transportation through data
- Website: https://mobilitydata.org/
- Location: Canada
- Twitter:
- Company:
- Icon url: https://avatars.githubusercontent.com/u/41021710?v=4
- Repositories: 32
- Last ynced at: 2025-04-24T10:44:53.858Z
- Profile URL: https://github.com/MobilityData
GitHub Events
Total
- Create event: 24
- Commit comment event: 3
- Issues event: 14
- Watch event: 37
- Delete event: 16
- Issue comment event: 113
- Push event: 51
- Pull request review comment event: 13
- Pull request event: 67
- Pull request review event: 53
- Fork event: 7
Last Year
- Create event: 24
- Commit comment event: 3
- Issues event: 14
- Watch event: 37
- Delete event: 16
- Issue comment event: 113
- Push event: 51
- Pull request review comment event: 13
- Pull request event: 67
- Pull request review event: 53
- Fork event: 7
Committers metadata
Last synced: 4 days ago
Total Commits: 632
Total Committers: 141
Avg Commits per committer: 4.482
Development Distribution Score (DDS): 0.835
Commits in past year: 63
Committers in past year: 14
Avg Commits per committer in past year: 4.5
Development Distribution Score (DDS) in past year: 0.302
Name | Commits | |
---|---|---|
Mitch Vars | m****h@m****g | 104 |
Fabien Richard-Allouard | f****n@m****g | 78 |
Josee Sabourin | 6****n | 40 |
Mitch Vars | m****h@g****m | 26 |
heidiguenin | 3****n | 26 |
Jesse Chan-Norris | j****e@c****m | 24 |
Sean Barbeau | s****u@g****m | 22 |
Frédéric Simard | f****r@m****g | 20 |
Alley Hector | a****r@m****m | 10 |
Francois Boucher | 1****C | 9 |
Aaron Antrim | a****n@t****m | 8 |
Brooke McKim | b****m | 7 |
Emmett McKinney | 4****n | 7 |
davevsdave | a****n@g****m | 7 |
michalmiesiak | m****k@q****m | 7 |
Daniel | 3****h | 7 |
allcontributors[bot] | 4****] | 6 |
Marcin Pyla | c****i@c****t | 6 |
Cyrille Medard de Chardon | s****c | 6 |
Andrew Fischer | a****r | 6 |
Chartsiri Jirachotkulthorn | 5****i | 5 |
Heidi G | 3****G | 5 |
Peter C | 6****c | 5 |
Tom | 1****s | 5 |
isabelle-dr | 6****r | 5 |
dsgermain | d****n | 4 |
Cameron Monagle | cm@c****m | 4 |
Benoit Deldicque | b****e@f****m | 4 |
Marc-André Dupras | m****s@p****m | 3 |
Erik Moedt | 5****t | 3 |
and 111 more... |
Committer domains:
- mobilitydata.org: 6
- motivateco.com: 3
- trilliumtransit.com: 2
- trekbikes.com: 2
- nextbike.net: 2
- skylinetechnologies.com: 1
- citiz.fr: 1
- raumobil.com: 1
- google.com: 1
- cityofchicago.org: 1
- interline.io: 1
- transport.data.gouv.fr: 1
- movo.me: 1
- labesse.me: 1
- niceridemn.org: 1
- louisvilleky.gov: 1
- utexas.edu: 1
- contra.io: 1
- pbsc.com: 1
- fysiki.com: 1
- cameronmonagle.com: 1
- cubbi.net: 1
- qucit.com: 1
- channorris.com: 1
- hannes-olszewski.dev: 1
- alumni.stanford.edu: 1
- pichot.us: 1
- cassee.net: 1
- danieldemmel.me: 1
- tomerikstower.com: 1
- mostlikelykevin.com: 1
- leonard.io: 1
- camazotz.com: 1
- gmx.de: 1
- mwillmott.co: 1
- andyfreeland.net: 1
- blvd.no: 1
- arzhel.younsi.org: 1
- redislabs.com: 1
- misix.com: 1
- indigo.co.jp: 1
- me.com: 1
- samgutentag.com: 1
- flanera.net: 1
- remix.com: 1
- cyclehop.com: 1
- kde.org: 1
- spin.pm: 1
Issue and Pull Request metadata
Last synced: 1 day ago
Total issues: 201
Total pull requests: 517
Average time to close issues: 9 months
Average time to close pull requests: 27 days
Total issue authors: 114
Total pull request authors: 144
Average comments per issue: 6.13
Average comments per pull request: 3.07
Merged pull request: 460
Bot issues: 0
Bot pull requests: 3
Past year issues: 17
Past year pull requests: 74
Past year average time to close issues: 2 months
Past year average time to close pull requests: 4 days
Past year issue authors: 12
Past year pull request authors: 16
Past year average comments per issue: 3.29
Past year average comments per pull request: 1.35
Past year merged pull request: 67
Past year bot issues: 0
Past year bot pull requests: 0
Top Issue Authors
- josee-sabourin (10)
- mplsmitch (10)
- heidiguenin (6)
- richfab (5)
- tdelmas (5)
- christrillium (5)
- fkh (5)
- afischer (4)
- edwinvandenbelt (4)
- keijipoon (4)
- viestat (3)
- PierrickP (3)
- evansiroky (3)
- jcn (3)
- benwedge (3)
Top Pull Request Authors
- richfab (93)
- mplsmitch (81)
- josee-sabourin (23)
- jcn (13)
- barbeau (12)
- heidiguenin (10)
- fbouchPBSC (9)
- brookemckim (9)
- tdelmas (8)
- michalmiesiak (7)
- ezmckinn (7)
- nbdh (7)
- ji-chartsiri (7)
- antrim (6)
- yocontra (6)
Top Issue Labels
- gbfs.md (66)
- Moved to PR (53)
- stale (38)
- systems.csv (25)
- proposal:breaking (10)
- question (4)
- v3.0-RC (3)
- proposal:nonbreaking (3)
- feed issue (3)
- README.md (2)
- v3.0-RC2 (1)
- governance.md (1)
- v3.1-RC2 (1)
- blocked (1)
Top Pull Request Labels
- systems.csv (292)
- gbfs.md (108)
- Vote Passed (45)
- README.md (20)
- v3.0-RC (15)
- proposal:nonbreaking (9)
- v2.3 (6)
- v3.0-RC2 (6)
- v2.0 (6)
- stale (5)
- v1.1 (5)
- v2.3-RC2 (5)
- v2.1 (3)
- v3.1-RC2 (3)
- v2.2 (2)
- proposal:breaking (2)
- v3.1-RC (2)
- v4.0-RC (2)
- Vote Failed (1)
- governance.md (1)
- Vote open (1)
Dependencies
- actions/checkout v2 composite
- actions/setup-node v1 composite
- 1password/load-secrets-action v1 composite
- actions/stale v5.2.1 composite
Score: 11.678583960867645