On this page:
- Guidance for public agencies
- RFP and contract examples
In 2015, a group of mobility apps, cities, and bikeshare operators convened by the North American Bikeshare Association (NABSA) developed the General Bikeshare Feed Specification (GBFS) so that bikeshare could be integrated into multimodal trip planning apps. Since then, GBFS has been modified to include free-floating bikeshare and scooter services, and has been adopted by more than half of all cities with bikeshare and scooter programs. While GBFS has been successful as a baseline data standard for information about shared micromobility, there are still improvements to be made, as feed quality, licensing terms, maintenance, and ease of access for third parties remain far from uniform.
Like GTFS, GBFS provides real-time information about available services, and does not allow riders to pay for or unlock a ride. Today, only a handful of bike and scooter share operators across North America have complete integrations in navigation apps like Transit through private APIs. In recent years, some bikeshare operators that previously shared private APIs to pay for and unlock rides have been acquired by larger mobility operators and shut down this functionality.
Despite the lack of a data standard for payment and unlocking, there is some progress towards deeper integration of bikeshare and scooters services with mobility apps such as Transit. Much like mobile payment for public transit, where no data standard yet exists, public agencies have helped encourage these integrations by encouraging their partners to work together and asking for past examples of payment and booking integrations during the RFP or permitting process.
Guidance for public agencies
- Cities with bikeshare and scooter programs can follow Transit’s Best Practices for GBFS, as well as NABSA’s Data Good Practices for Municipalities and MobilityData's Shared Mobility Data Policy guidance, which all encourage requiring a publicly-accessible GBFS feed whenever a micromobility service is introduced.
- Ensure easy public access by mandating public GBFS feeds that do not require authentication. Post the URL for each operator’s gbfs.json file on the municipality's website or open data portal.
- Require that operators license GBFS data using a permissive license that places minimal restrictions on usage to ensure that apps, developers, researchers, and advocates can use GBFS data without onerous restrictions. Encourage the use of standard open source data licenses.
- Require that operators include their GBFS feed information in the GBFS systems.csv file in NABSA’s GitHub repository.
- As part of the RFP or permitting process, regulators can request that operators build and provide a payment experience available in third-party apps.
- Past experience is a good indicator of future success. Public agencies can ask operators for documented examples of previous third-party trip planning and payment integrations for their services.
RFP and contract examples
This page will be regularly updated with new RFP and contract examples.
San Francisco, CA: The city-county’s 2021 permit requirements specify that “permittees must expose a public General Bikeshare Feed Specification (GBFS) feed. If authentication is required, permittees must provide instructions that can be posted on the SFMTA website to guide the public on how to obtain the appropriate token or credentials.”
Los Angeles, CA: The city’s 2019 dockless on-demand permit specifies that: “Operators shall provide a publicly accessible API that meets the requirements of the General Bikeshare Feed Specification (https://github.com/NABSA/gbfs). The Operator may not change the API URL without notifying the City with at least 30 days’ notice. Operators are required to make the API endpoint available for public consumption.”
New York, NY: NYC DOT’s 2020 Scooter Request for Expression of Interest: “A public E-Scooter service API shall be provided that complies with the current version (v2.0 or more recent) of North American Bike Share Association’s General Bikeshare Feed Specification (GBFS) as detailed at: https://github.com/NABSA/gbfs/blob/v2.0/gbfs.md. The participating Project Vendor(s) must keep current with minor version alterations of GBFS within six weeks of release or to a specific patch version, as specified by NYCDOT. Vendor(s) must inform NYCDOT when version alteration transition will occur at least seventy-two (72) hours in advance;”
Kelowna, BC: The city’s 2021 bikeshare permit program specifies that “All Permit Holders must generate a GBFS compliant, publicly available data feed. Real‐time information about the system and Bikeshare Device availability is to be published using the General Bikeshare Feed Specification (GBFS) v1.0 or the most current (https://github.com/NABSA/gbfs). Permit Holders will need to inform The City of the location of the gbfs.json file on the internet. The gbfs.json file contains the necessary information to find other files related to the GBFS data. This feed must be publicly available via an https endpoint.”
Payment and Unlocking
Chicago, IL: The city’s 2019 contract with Divvy’s operator (Lyft) requires Lyft to “work cooperatively, and in good faith, to enable integrations and [...] enable purchase of rides at publicly available rates.” (see section 2.8 of contract)
Denver, CO: A 2020 RFQ from the City of Denver for shared micromobility services asked respondents to “outline their proposed solution for users to pay for and retrieve Vehicles, including the feasibility of integrating shared micromobility with existing transit fare payment tools.” (see page 11 of RFP)
Antwerp, Belgium: The city’s most recent scooter permit required operators to integrate at the transaction level with “at least three local Mobility as a Service operators,” selected from a list of apps pre-approved by the City (see page 5 of rules available here). As a response to these requirements, Bird has built a transaction-level integration with multimodal app Skipr.
Calgary, AB: In its 2021 scooter RFP, the city let operators know it preferred e-scooter operators with “Experience in MaaS” or who had “integrated MaaS in other jurisdictions.” It also asked operators to “provide examples where your operations were integrated into a MaaS application. Each example should include the following information: i. City and agencies involved, ii. Level of integration (payment, trip -planning), and iii. Customer experience/ratings.” (see page 35 of the city’s e-scooter permit application)