GBFS is a specification that allows specifying information about shared mobility. It originated in the bike industry, maintained by MobilityData.

source

It contains data about several data concepts, with the general idea that this data is relevant for the end-user and planning tools.

Concept	Remark
General information	system_information: Details including system operator, system location, year implemented, URL, contact info, time zone. station_information: List of all stations, their capacities and locations. REQUIRED of systems utilizing docks.
Vehicle information	vehicle_types: Describes the types of vehicles that system operator has available for rent. REQUIRED of systems that include information about vehicle types in the free_bike_status.json file. If this file is not included, then all vehicles in the feed are assumed to be non-motorized bicycles.
Availability	free_bike_status: (as of v2.1) Describes all vehicles that are not currently in active rental. REQUIRED for free floating (dockless) vehicles. OPTIONAL for station based (docked) vehicles. Vehicles that are part of an active rental MUST NOT appear in this feed. vehicle_status (after v2.1) station_status:Number of available vehicles and docks at each station and station availability. REQUIRED of systems utilizing docks.
Operating times	system_calendar: dates of operation for the system. system_hours: Hours of operation for the system.
Areas	system_regions: system_regions: Regions the system is broken up into. geofencing_zones: Geofencing zones and their associated rules and attributes.
Prices	system_pricing_plans: System pricing scheme.
Other	system_alerts: Current system alerts.

The information above is sometimes altered to apply in other situations, like sharing information between the city and bike operators.

• In vehicle_status / free_bike_status the vehicle id can be misused, and track where vehicles are rented and where vehicles are returned. This conflicts with privacy regulations; people tend to rent the same bike/scooter and their whereabouts are discoverable.

The endpoint for publishing free bikes (or assets)

similar to 'free bike status', but with static asset-ids. This has the consequence that the asset can be tracked from rental to return. It creates the possibility to determine Origin-Destination matrices. The negative side is that it is pseudo personal information. According to GDPR it requires bilateral agreements and DPIAs.

speed limits, parking, and accessibility areas.

operating areas

The newer version of 'free bike status'

The newer version of 'Free bike status with non-rotating asset-ids', but with the same advantage and disadvantage.

The fields in the JSON are described here, but only those that need explanation. The values in the building block, are fixed, unless they are between square brackets ([]).

name	required	value	description
exchangeType	*	must be API OR file-based	Both options are valid; dependent on the chosen value, authentication can be different.
version	*	[1.1 < version < 2.1]	The allowed version(s), comma separated. Replace this value by f.x. "1.2,2.0,2.1"
url	*	[url]	The URL where this file (or endpoint) can be found, f.x. "https://example.transporter.com/gbfs/system_regions.json"
refreshRate		[refresh rate]	The refresh frequency. Specified in 8601 Duration (see https://en.wikipedia.org/wiki/ISO_8601#Durations). f.x. "PT5M" for 5 minutes.

name	value	argumentation
privacy	A	Availability: When implemented as described on Github-GBFS, with rotating IDs, it is almost impossible to derive personal movements. Therefore it is marked as an A. When it is misused (fixed IDs), it drops to C. When it is used together with a use case about origin-destination, it fits the purpose, and it can rise again to B. Be aware of the GDPR mitigative actions you have to take! Others: no personal information, A.
implementationEffort	B	When it is implemented as separate files, it is the simplest implementation, an A. This limits also the possibility to authenticate, and the available assets files more or less require an API endpoint solution. Therefore it is marked as a B.
reusability	A	Availability: This data can be applied in several domains, to exchange between TO and MPs, towards route planners and to cities. Whenever a modification is made (static ids), it drops directly to E. Others: fully reusable, A
interoperability	A	This is a worldwide standard (A).
domain	B	When applied in the domain city-transport operator, it would be an A, but this standard is made to exchange data in the mobility domain. Not a perfect fit.