# General Bikeshare Feed Specification (GBFS) This document explains the types of files and data that comprise the General Bikeshare Feed Specification (GBFS) and defines the fields used in all of those files. ## Reference version This documentation refers to **v3.1-RC**. For past and upcoming versions see the [README](https://github.com/MobilityData/gbfs/blob/master/README.md#current-version-recommended). ## Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119](https://tools.ietf.org/html/rfc2119), [BCP 14](https://tools.ietf.org/html/bcp14) and [RFC8174](https://tools.ietf.org/html/rfc8174) when, and only when, they appear in all capitals, as shown here. ## Table of Contents * [Introduction](#introduction) * [Term Definitions](#term-definitions) * [Files](#files) * [Accessibility](#accessibility) * [File Requirements](#file-requirements) * [Licensing](#licensing) * [Field Types](#field-types) * [Files](#files) * [gbfs.json](#gbfsjson) * [manifest.json](#manifestjson) *(added in v3.0)* * [gbfs_versions.json](#gbfs_versionsjson) * [system_information.json](#system_informationjson) * [vehicle_types.json](#vehicle_typesjson) *(added in v2.1)* * [station_information.json](#station_informationjson) * [station_status.json](#station_statusjson) * [vehicle_status.json](#vehicle_statusjson) *(formerly free_bike_status.json)* * [system_hours.json](#system_hoursjson) *(removed in v3.0)* * [system_calendar.json](#system_calendarjson) *(removed in v3.0)* * [system_regions.json](#system_regionsjson) * [system_pricing_plans.json](#system_pricing_plansjson) * [system_alerts.json](#system_alertsjson) * [geofencing_zones.json](#geofencing_zonesjson) *(added in v2.1)* * [Deep Links - Analytics and Examples](#deep-links) ## Introduction This 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 specification supports real-time travel advice in GBFS-consuming applications. ## Term Definitions This section defines terms that are used throughout this document. * JSON - (JavaScript Object Notation) is a lightweight format for storing and transporting data. This document uses many terms defined by the JSON standard, including field, array, and object. (https://www.w3schools.com/js/js_json_datatypes.asp) * Field - In JSON, a name/value pair consists of a field name (in double quotes), followed by a colon, followed by a value. (https://www.w3schools.com/js/js_json_syntax.asp) * GeoJSON - GeoJSON is a format for encoding a variety of geographic data structures. (https://geojson.org/) * REQUIRED - The field MUST be included in the dataset, and a value MUST be provided in that field for each record. (A required field inside an OPTIONAL Object is only required when the Object is present.) * OPTIONAL - The field MAY be omitted from the dataset. If an OPTIONAL column is included, some of the entries in that field MAY be empty strings. An omitted field is equivalent to a field that is empty. * Conditionally REQUIRED - The field or file is REQUIRED under certain conditions, which are outlined in the field or file description. Outside of these conditions, this field or file is OPTIONAL. ## Files File Name | REQUIRED | Defines ---|---|--- gbfs.json | Yes
*(as of v2.0)* | Auto-discovery file that links to the other files published for the system. To avoid circular references this file MUST NOT contain links to `manifest.json`. manifest.json *(added in v3.0)* | Conditionally REQUIRED | Required of any GBFS dataset provider that publishes more than one GBFS dataset. For example, if you publish one set of files for Berlin and a different set for Paris, this file is REQUIRED. A discovery file containing a comprehensive list of `gbfs.json` URLs for all GBFS datasets published by the provider. gbfs_versions.json | OPTIONAL | Lists all feed endpoints published according to versions of the GBFS documentation. system_information.json | Yes | Details including system operator, system location, year implemented, URL, contact info, time zone. vehicle_types.json
*(added in v2.1)* | Conditionally REQUIRED | Describes the types of vehicles that System operator has available for rent. REQUIRED of systems that include information about vehicle types in the `vehicle_status` file. If this file is not included, then all vehicles in the feed are assumed to be non-motorized bicycles. station_information.json | Conditionally REQUIRED | List of all stations, their capacities and locations. REQUIRED of systems utilizing docks. station_status.json | Conditionally REQUIRED | Number of available vehicles and docks at each station and station availability. REQUIRED of systems utilizing docks. vehicle_status.json | Conditionally REQUIRED | *(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. system_hours.json | - | This file is removed *(as of v3.0)*. See `system_information.opening_hours` for system hours of operation. system_calendar.json | - | This file is removed *(as of v3.0)*. See `system_information.opening_hours` for system dates of operation. system_regions.json | OPTIONAL | Regions the system is broken up into. system_pricing_plans.json | OPTIONAL | System pricing scheme. system_alerts.json | OPTIONAL | Current system alerts. geofencing_zones.json
*(added in v2.1)* | OPTIONAL | Geofencing zones and their associated rules and attributes. ## Accessibility Datasets SHOULD be published at an easily accessible, public, permanent URL. (for example, https://www.example.com/gbfs/v3/gbfs.json). The URL SHOULD be directly available without requiring login to access the file to facilitate download by consuming software applications. To be compliant with GBFS, all systems MUST have an entry in the [systems.csv](https://github.com/MobilityData/gbfs/blob/master/systems.csv) file. ### Feed Availability Automated tools for application performance monitoring SHOULD be used to ensure feed availability. Producers MUST provide a technical contact who can respond to feed outages in the `feed_contact_email` field in the `system_information.json` file. ### Seasonal Shutdowns, Disruptions of Service, Termination of Service Feeds SHOULD continue to be published during seasonal or temporary shutdowns. Feed URLs SHOULD NOT return a 404. An empty vehicles array SHOULD be returned by `vehicle_status.json`. Stations in `station_status.json` SHOULD be set to `is_renting:false`, `is_returning:false` and `is_installed:false` where applicable. Seasonal shutdown dates SHOULD be reflected using `opening_hours` in `system_information.json`. Announcements for disruptions of service, including disabled stations or temporary closures of stations or systems SHOULD be made in `system_alerts.json`. Permanent shutdowns resulting in the termination of service SHOULD be communicated to data consumers via `system_information.json#termination_date`. ### Hours and Dates of Operation Beginning with v3.0, hours and dates of operation are described using the Open Street Map [opening_hours](https://wiki.openstreetmap.org/wiki/Key:opening_hours) format. The OSM opening_hours syntax is quite complex, therefore it is RECOMMENDED that publishers validate their opening_hours data to ensure its accuracy. * [OSM opening_hours examples](https://wiki.openstreetmap.org/wiki/Key:opening_hours) * [OSM opening_hours syntax guide](https://wiki.openstreetmap.org/wiki/Key:opening_hours/specification) * [OSM opening_hours validation tool](https://openingh.openstreetmap.de/evaluation_tool/) * [OSM opening_hours project and code libraries](https://github.com/opening-hours) Hours and dates of operation SHOULD be published even in cases where services are continuously available 24/7. During periods when a system or station is outside of opening hours, stations SHOULD be set to `is_renting = false`. During these periods, `station_status.json.num_vehicles_available` and `station_status.json.num_docks_available` SHOULD reflect the number of vehicles and docks that would be available if the system or station were open. The `vehicles` array in `vehicle_status` SHOULD reflect those vehicles that are in the field and accessible to users that would be available for rental if the system were open. ## File Requirements * All files MUST be valid JSON * All files in the spec MAY be published at a URL path or with an alternate name (e.g., `station_info` instead of `station_information.json`) *(as of v2.0)*. * All data MUST be UTF-8 encoded * All deep links MUST use HTTPS * Line breaks MUST be represented by unix newline characters only (\n) * Pagination is not supported. ### File Distribution * Files are distributed as individual HTTP endpoints. * All endpoints MUST use HTTPS * REQUIRED files MUST NOT 404. They MUST return a properly formatted JSON file as defined in [Output Format](#output-format). * OPTIONAL files MAY 404. A 404 of an OPTIONAL file SHOULD NOT be considered an error. ### Version Endpoints The version of the GBFS specification to which a feed conforms is declared in the `version` field in all files. See [Output Format](#output-format). All endpoints within a data set SHOULD conform to the same MAJOR or MINOR version. Mixing of versions within data sets is NOT RECOMMENDED.
GBFS documentation will include a list of current and past supported MAJOR and MINOR versions. Supported versions SHALL NOT span more than two MAJOR versions. 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. Producers SHOULD continue to maintain existing feeds while they have _Supported_ status. GBFS producers SHOULD provide endpoints that conform to the current MAJOR version release within 180 days of a new MAJOR version release. It is not necessary to support more than one MINOR release of the same MAJOR release group, because MINOR releases are backwards-compatible. See [Specification Versioning](https://github.com/MobilityData/gbfs/blob/master/README.md#specification-versioning). ### Auto-Discovery Publishers SHOULD implement auto-discovery of GBFS feeds by linking to the location of the `gbfs.json` auto-discovery endpoint. * The location of the auto-discovery file SHOULD be provided in the HTML area of the shared mobility landing page hosted at the URL specified in the `url` field of the `system_information.json` file. * This is referenced via a _link_ tag with the following format: * `` * References: * https://microformats.org/wiki/existing-rel-values * https://microformats.org/wiki/rel-faq#How_is_rel_used * A shared mobility landing page MAY contain links to auto-discovery files for multiple systems. ### Localization * Each supported language MUST be listed in the `languages` field in `system_information.json`. *(as of v3.0)* * Translations MUST be provided for each supported language for all translateable fields of type Array<[Localized String](#localized-string)> and Array<[Localized URL](#localized-url)>. *(as of v3.0)* * URLs pointing to text intended for consumption by end-users MUST be provided for each supported language. *(as of v3.0)* ### Text Fields and Naming Rich text SHOULD NOT be stored in free form text fields. Fields SHOULD NOT contain HTML. All customer-facing text strings (including station names) SHOULD use Mixed Case (not ALL CAPS), following local conventions for capitalization of place names on displays capable of displaying lower case characters. * Examples: * Central Park South * Villiers-sur-Marne * Market Street Abbreviations SHOULD NOT be used for names and other text (for example, St. for Street), unless a location is called by its abbreviated name (for example, “JFK Airport”). Abbreviations may be problematic for accessibility by screen reader software and voice user interfaces. Consuming software can be engineered to reliably convert full words to abbreviations for display, but converting from abbreviations to full words is prone to more risk of error. Names used for stations, virtual stations, and geofenced areas SHOULD be human-readable. Naming conventions used for locations SHOULD consider a variety of use cases including both text and maps. Descriptions SHOULD NOT include information so specific that it could be used in tracking of vehicles or trips. ### Coordinate Precision Feeds SHOULD provide 6 digits (0.000001) of precision for decimal degrees lat/lon coordinates. Decimal places | Degrees | Distance at the Equator ---|---|--- 0|1.0|111 km 1|0.1|11.1 km 2|0.01|1.11 km 3|0.001|111 m 4|0.0001|11.1 m 5|0.00001|1.11 m **6**|**0.000001**|**0.11 m** 7|0.0000001|1.11 cm ### Data Latency The data returned by the near-realtime endpoints `station_status.json` and `vehicle_status.json` SHOULD be as close to realtime as possible, but in no case should it be more than 5 minutes out-of-date. Appropriate values SHOULD be set using the `ttl` property for each endpoint based on how often the data in feeds are refreshed or updated. For near-realtime endpoints where the data should always be refreshed, the `ttl` value SHOULD be `0`. The `last_updated` timestamp represents the publisher's knowledge of the current state of the system at this point in time. The `last_reported` timestamp represents the last time a station or vehicle reported its status to the operator's backend. ## Licensing It is RECOMMENDED that all GBFS data sets be offered under an open data license. Open data licenses allow consumers to freely use, modify, and share GBFS data for any purpose in perpetuity. Licensing of GBFS data provides certainty to GBFS consumers, allowing them to integrate GBFS data into their work. All GBFS data sets SHOULD specify a license using the `license_id` field with an [SPDX identifier](https://spdx.org/licenses/) or by using the `license_url` field with a URL pointing to a custom license in `system_information.json`. See the GBFS repo for a [comparison of a subset of standard licenses](https://github.com/MobilityData/gbfs/blob/master/data-licenses.md). ## Field Types * Array - A JSON element consisting of an ordered sequence of zero or more values. * Array<Type> - A JSON element consisting of an ordered sequence of zero or more values of the specified sub-type. * Boolean - One of two possible values, `true` or `false`. Boolean values MUST be JSON booleans, not strings (meaning `true` or `false`, not `"true"` or `"false"`). *(as of v2.0)* * Country code - Country code following the [ISO 3166-1 alpha-2 notation](https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2). * Date - A date in the [ISO 8601](https://en.wikipedia.org/wiki/ISO_8601) Complete Date Extended Format: YYYY-MM-DD. Example: `2019-09-13` for September 13th, 2019. * Datetime *(added in v2.3)*- Combination of a date and a time following [ISO 8601 notation](https://www.iso.org/iso-8601-date-and-time-format.html). Attributes : [year](https://docs.python.org/3/library/datetime.html#datetime.datetime.year), [month](https://docs.python.org/3/library/datetime.html#datetime.datetime.month), [day](https://docs.python.org/3/library/datetime.html#datetime.datetime.day), [hour](https://docs.python.org/3/library/datetime.html#datetime.datetime.hour), [minute](https://docs.python.org/3/library/datetime.html#datetime.datetime.minute), [second](https://docs.python.org/3/library/datetime.html#datetime.datetime.second), and timezone. * Email - An email address. Example: `example@example.com` * Enum (Enumerable values) - An option from a set of predefined constants in the "Defines" column. Enum values MUST (as of v3.0) be lowercase. Example: The `rental_methods` field contains values `creditcard`, `paypass`, etc... * Float *(added in v2.1)* - A 32-bit floating point number. * GeoJSON FeatureCollection - A FeatureCollection as described by the IETF RFC 7946 https://tools.ietf.org/html/rfc7946#section-3.3. * GeoJSON MultiPolygon - A Geometry Object as described by the IETF RFC https://tools.ietf.org/html/rfc7946#section-3.1.7. * ID - Should be represented as a string that identifies that particular entity. An ID: * MUST be unique within like fields (for example, `station_id` MUST be unique among stations) * Does not have to be globally unique, unless otherwise specified * MUST be in the ASCII printable character range, space excluded (0x21 to 0x7E) https://en.wikipedia.org/wiki/ASCII#Printable_characters *(as of v3.0)* * SHOULD be restricted to `A-Z`, `a-z`, `0-9` and `.@:/_-` *(as of v3.0)* * MUST be persistent for a given entity (station, plan, etc.). An exception is `vehicle_id`, which MUST NOT be persistent between rentals for privacy reasons (see `vehicle_status.json`). *(as of v2.0)* * Language - An IETF BCP 47 language code. For an introduction to IETF BCP 47, refer to https://www.rfc-editor.org/rfc/bcp/bcp47.txt and https://www.w3.org/International/articles/language-tags/. Examples: `en` for English, `en-US` for American English, or `de` for German. * Latitude - WGS84 latitude in decimal degrees. The value MUST be greater than or equal to -90.0 and less than or equal to 90.0. Example: `41.890169` for the Colosseum in Rome. * Longitude - WGS84 longitude in decimal degrees. The value MUST be greater than or equal to -180.0 and less than or equal to 180.0. Example: `12.492269` for the Colosseum in Rome. * Localized String - A JSON element representing a String value that has been translated into a specific language. The element consists of the following name-value pairs: Field Name | REQUIRED | Type | Defines ---|---|---|--- `text` | Yes | String | The translated text. `language` | Yes | Language | IETF BCP 47 language code. Must match one of the values specified by the `languages` field in `system_information.json`. Most commonly specified as `Array` when specifying translations in multiple languages. See [Localization](#localization) for more details. * Localized URL - A JSON element representing the URL of a resource that has been translated into a specific language. The element consists of the following name-value pairs: Field Name | REQUIRED | Type | Defines ---|---|---|--- `text` | Yes | URL | The URL of the translated resource. `language` | Yes | Language | IETF BCP 47 language code. Must match one of the values specified by the `languages` field in `system_information.json`. * Non-negative Float - A 32-bit floating point number greater than or equal to 0. * Non-negative Integer - An integer greater than or equal to 0. * Object - A JSON element consisting of key-value pairs (fields). * Phone Number *as of v3.0* - Phone number in [E.164](https://www.itu.int/rec/T-REC-E.164-201011-I/en) format. The phone number MUST start with a "+". The characters following the "+" MUST be integers and MUST NOT contain any hyphens, spaces or parentheses. * String - Can only contain text. Strings MUST NOT contain any formatting codes (including HTML) other than newlines. * Time - Service time in the HH:MM:SS format for the time zone indicated in `system_information.json` (00:00:00 - 47:59:59). Time can stretch up to one additional day in the future to accommodate situations where, for example, a system was open from 11:30pm - 11pm the next day (23:30:00-47:00:00). * Timestamp - Timestamp fields MUST be represented as strings in [RFC3339 format](https://www.rfc-editor.org/rfc/rfc3339), for example `2023-07-17T13:34:13+02:00`. *(as of v3.0)* * Timezone - TZ timezone from the https://www.iana.org/time-zones. Timezone names never contain the space character but MAY contain an underscore. Refer to https://en.wikipedia.org/wiki/List_of_tz_zones for a list of valid values. Example: `Asia/Tokyo`, `America/Los_Angeles` or `Africa/Cairo`. * URI - A fully qualified URI that includes the scheme (for example, `com.example.android://`). Any special characters in the URI MUST be correctly escaped. See the following https://www.w3.org/Addressing/URL/4_URI_Recommentations.html for a description of how to create fully qualified URI values. Note that URIs MAY be URLs. * URL - A fully qualified URL that includes `http://` or `https://`. Any special characters in the URL MUST be correctly escaped. See the following https://www.w3.org/Addressing/URL/4_URI_Recommentations.html for a description of how to create fully qualified URL values. ### Extensions Outside of the Specification To accommodate the needs of feed producers and consumers prior to the adoption of a change, additional fields can be added to feeds even if these fields are not part of the official specification. Custom extensions that may provide value to the GBFS community and align with the [GBFS Guiding Principles](https://github.com/MobilityData/gbfs/blob/master/README.md#guiding-principles) SHOULD be proposed for inclusion in the specification through the change process. Extreme caution is advised to avoid introducing extensions which may be used to track the movements of vehicles or their users. Field names of extensions SHOULD be prefixed with an underscore (_) character. It is strongly RECOMMENDED that these additional fields be documented on [gbfs.org](https://gbfs.org/specification/#extensions-outside-of-the-specification) in this format: Field Name | File Name | Organization name | Defines ---|---|---|--- _field_name | Name of GBFS endpoint where field is used | Publisher's name | Description of purpose or use ## JSON Files ### Output Format Every JSON file presented in this specification contains the same common header information at the top level of the JSON response object: Field Name | REQUIRED | Type | Defines ---|---|---|--- `last_updated` | Yes | Timestamp | Indicates the last time data in the feed was updated. This timestamp represents the publisher's knowledge of the current state of the system at this point in time. `ttl` | Yes | Non-negative integer | Number of seconds before the data in the feed will be updated again (0 if the data should always be refreshed). `version` | Yes | String | GBFS version number to which the feed conforms, according to the versioning framework. `data` | Yes | Object | Response data in the form of name:value pairs. **Example:** ```json { "last_updated": "2023-07-17T13:34:13+02:00", "ttl": 3600, "version": "3.1-RC", "data": { "name": [ { "text": "Example Bike Rental", "language": "en" } ], "system_id": "example_cityname", "timezone": "America/Chicago", "languages": ["en"] } } ``` ### gbfs.json The `gbfs.json` discovery file SHOULD represent a single system or geographic area in which vehicles are operated. The location (URL) of the `gbfs.json` file SHOULD be made available to the public using the specification’s [auto-discovery](#auto-discovery) function. To avoild circular references, this file MUST NOT contain links to `manifest.json` files.*(as of v3.0)*
The following fields are all attributes within the main `data` object for this feed. Field Name | REQUIRED | Type | Defines ---|---|---|--- `feeds` | Yes | Array<Object> | An array of all of the feeds that are published by this auto-discovery file. `feeds[].name` | Yes | String | Key identifying the type of feed this is. The key MUST be the base file name defined in the spec for the corresponding feed type ( `system_information` for `system_information.json` file, `station_information` for `station_information.json` file). `feeds[].url` | Yes | URL | URL for the feed. Note that the actual feed endpoints (urls) may not be defined in the `file_name.json` format. For example, a valid feed endpoint could end with `station_info` instead of `station_information.json`. **Example:** ```json { "last_updated": "2023-07-17T13:34:13+02:00", "ttl": 0, "version": "3.1-RC", "data": { "feeds": [ { "name": "system_information", "url": "https://www.example.com/gbfs/1/system_information" }, { "name": "station_information", "url": "https://www.example.com/gbfs/1/station_information" } ] } } ``` ### manifest.json *(added in v3.0)* An index of `gbfs.json` URLs for each GBFS data set produced by a publisher. A single instance of this file should be published at a single stable URL, for example: `https://example.com/gbfs/manifest.json` The following fields are all attributes within the main `data` object for this feed. Field Name | REQUIRED | Type | Defines ---|---|---|--- `datasets` | Yes | Array<Object> | An array of `datasets` produced by a publisher. `datasets[].system_id` | Yes | ID | The `system_id` from `system_information.json` for the corresponding data set(s). `datasets[].versions` | Yes | Array<Object> | Contains one object for each of the available versions of a feed. The array MUST be sorted by increasing MAJOR and MINOR version number. `datasets[].versions[].version` | Yes | String | The semantic version of the feed in the form `X.Y`. `datasets[].versions[].url` | Yes | URL | URL of the corresponding `gbfs.json` endpoint. `datasets[].area`
*(added in v3.1-RC)* | OPTIONAL | GeoJSON MultiPolygon | A GeoJSON MultiPolygon that describes the operating area. If `area` is supplied, then the record describes the general operating area of the system for the purpose of discovery. Geographic details of the system's operating restrictions must be explicitly specified using station locations and geofencing zones, where appropriate. `datasets[].country_code`
*(added in v3.1-RC)* | OPTIONAL | Country Code | The ISO 3166-1 alpha-2 country code of the operating area. The field MUST NOT be specified if the operating area spans multiple countries. **Example:** ```json { "last_updated": "2023-07-17T13:34:13+02:00", "ttl":0, "version": "3.1-RC", "data":{ "datasets":[ { "system_id":"example_berlin", "versions":[ { "version": "2.0", "url":"https://berlin.example.com/gbfs/2/gbfs" }, { "version": "3.1-RC", "url":"https://berlin.example.com/gbfs/3.1-RC/gbfs" } ], "area": { "type": "MultiPolygon", "coordinates": [ [ [ [ 13.10821, 52.58563 ], [ 13.29743, 52.67046 ], [ 13.48451, 52.6855 ], [ 13.77993, 52.43458 ], [ 13.65355, 52.33048 ], [ 13.08165, 52.38793 ], [ 13.10821, 52.58563 ] ] ] ] }, "country_code": "DE" }, { "system_id":"example_paris", "versions":[ { "version": "2.0", "url":"https://paris.example.com/gbfs/2/gbfs" }, { "version": "3.1-RC", "url":"https://paris.example.com/gbfs/3.1-RC/gbfs" } ], "area": { "type": "MultiPolygon", "coordinates": [ [ [ [ 2.14306, 48.89971 ], [ 2.36707, 48.99455 ], [ 2.60219, 49.01987 ], [ 2.615, 48.69025 ], [ 2.52167, 48.6867 ], [ 2.26838, 48.73275 ], [ 2.13103, 48.80833 ], [ 2.14306, 48.89971 ] ] ] ] }, "country_code": "FR" } ] } } ``` ### gbfs_versions.json Each expression of a GBFS feed describes all of the versions that are available. The following fields are all attributes within the main `data` object for this feed. Field Name | REQUIRED | Type | Defines ---|---|---|--- `versions` | Yes | Array<Object> | Contains one object for each of the available versions of a feed. The array MUST be sorted by increasing MAJOR and MINOR version number. `versions[].version` | Yes | String | The semantic version of the feed in the form `X.Y`. `versions[].url` | Yes | URL | URL of the corresponding gbfs.json endpoint. **Example:** ```json { "last_updated": "2023-07-17T13:34:13+02:00", "ttl": 0, "version": "3.1-RC", "data": { "versions": [ { "version": "2.0", "url": "https://www.example.com/gbfs/2/gbfs" }, { "version": "3.1-RC", "url": "https://www.example.com/gbfs/3.1-RC/gbfs" } ] } } ``` ### system_information.json The following fields are all attributes within the main `data` object for this feed. Field Name | REQUIRED | Type | Defines ---|---|---|--- `system_id` | Yes | ID | This is a globally unique identifier for the vehicle share system. Each distinct system or geographic area in which vehicles are operated MUST have its own unique `system_id`. It is up to the publisher of the feed to guarantee uniqueness and MUST be checked against existing `system_id` fields in [systems.csv](https://github.com/MobilityData/gbfs/blob/master/systems.csv) to ensure this. This value is intended to remain the same over the life of the system.

System IDs SHOULD be recognizable as belonging to a particular system as opposed to random strings - for example, `bcycle_austin` or `biketown_pdx`. `languages`
*(added of v3.0)* | Yes | Array<Language> | List of languages used in translated strings. `name`
*(as of v3.0)* | Yes | Array<Localized String> | Name of the system to be displayed to customers. `opening_hours`
*(added in v3.0)*| Yes | String | Hours and dates of operation for the system in [OSM opening_hours](https://wiki.openstreetmap.org/wiki/Key:opening_hours) format. *(added in v3.0)* `short_name` *(as of v3.0)* | OPTIONAL | Array<Localized String> | Abbreviation for a system. `operator`
*(as of v3.0)* | OPTIONAL | Array<Localized String> | Name of the system operator. `url` | OPTIONAL | URL | The URL of the vehicle share system. `purchase_url` | OPTIONAL | URL | URL where a customer can purchase a membership. `start_date` | OPTIONAL | Date | Date that the system began operations. `termination_date`
*(added in v3.0)* | OPTIONAL | Date | Date after which this data source will no longer be available to consuming applications.

This OPTIONAL field SHOULD be used to notify 3rd party data consumers when a service is planning a permanent (non-seasonal) shutdown. Publishers SHOULD include this date in their feeds as soon as they know of an impending shutdown. Publishers SHOULD continue to publish feeds for 30 days following a permanent shutdown after which they SHOULD return a helpful http status code and text, for example `410 service no longer available ...` for all feed endpoint URLs. `phone_number`
*(as of v3.0)* | OPTIONAL | Phone Number | This OPTIONAL field SHOULD contain a single voice telephone number for the specified system’s customer service department. MUST be in [E.164](https://www.itu.int/rec/T-REC-E.164-201011-I/en) format as defined in [Field Types](#field-types). `email` | OPTIONAL | Email | This OPTIONAL field SHOULD contain a single contact email address actively monitored by the operator’s customer service department. This email address SHOULD be a direct contact point where riders can reach a customer service representative. `feed_contact_email` | Yes
*(as of v3.0)* | Email | This field MUST contain a single contact email for feed consumers to report issues with the feed. This email address SHOULD point to a stable email address, that does not correspond to an individual but rather the team or company that manages GBFS feeds. `manifest_url`
*(added in v3.0)* | Conditionally REQUIRED | URL | REQUIRED if the producer publishes datasets for more than one system geography, for example Berlin and Paris. A fully qualified URL pointing to the [manifest.json](#manifestjson) file for the publisher. `timezone` | Yes | Timezone | The time zone where the system is located. `license_id`
*(added in v3.0)* | Conditionally REQUIRED | String | REQUIRED if the dataset is provided under a standard license. An identifier for a standard license from the [SPDX License List](https://spdx.org/licenses/). Provide `license_id` rather than `license_url` if the license is included in the SPDX License List. See the GBFS wiki for a [comparison of a subset of standard licenses](https://github.com/MobilityData/gbfs/blob/master/data-licenses.md). If the `license_id` and `license_url` fields are blank or omitted, this indicates that the feed is provided under the [Creative Commons Universal Public Domain Dedication](https://creativecommons.org/publicdomain/zero/1.0/legalcode). `license_url` | Conditionally REQUIRED
*(as of v3.0)* | URL | REQUIRED if the dataset is provided under a customized license. A fully qualified URL of a page that defines the license terms for the GBFS data for this system. Do not specify a `license_url` if `license_id` is specified. If the `license_id` and `license_url` fields are blank or omitted, this indicates that the feed is provided under the [Creative Commons Universal Public Domain Dedication](https://creativecommons.org/publicdomain/zero/1.0/legalcode). *(as of v3.0)* `attribution_organization_name`
*(added in v3.0)* | OPTIONAL | Array<Localized String> | If the feed license requires attribution, name of the organization to which attribution should be provided. `attribution_url`
*(added in v3.0)* | OPTIONAL | URL | URL of the organization to which attribution should be provided. `brand_assets`
*(added in v2.3)* | OPTIONAL | Object | Object containing branding information about the system. `brand_assets.brand_last_modified`
*(added in v2.3)* | REQUIRED | Date | Date that indicates the last time any included brand assets were updated or modified. `brand_assets.brand_terms_url`
*(added in v2.3)* | OPTIONAL | URL | A fully qualified URL pointing to the location of a page that defines the license terms of brand icons, colors, or other trademark information. This field MUST NOT take the place of `license_url` or `license_id`. `brand_assets.brand_image_url`
*(added in v2.3)* | REQUIRED | URL | A fully qualified URL pointing to the location of a graphic file representing the brand for the service. File MUST be in SVG V1.1 format and MUST be either square or round. `brand_assets.brand_image_url_dark`
*(added in v2.3)* | OPTIONAL | URL | A fully qualified URL pointing to the location of a graphic file representing the brand for the service for use in dark mode applications. File MUST be in SVG V1.1 format and MUST be either square or round. `brand_assets.color`
*(added in v2.3)* | OPTIONAL | String | Color used to represent the brand for the service expressed as a 6 digit hexadecimal color code in the form #000000. `terms_url`
*(as of v3.0)* | OPTIONAL | Array<Localized String> | A fully qualified URL pointing to the terms of service (also often called "terms of use" or "terms and conditions") for the service. `terms_last_updated`
*(added in v2.3)* | REQUIRED | Date | The date that the terms of service provided at `terms_url` were last updated. `privacy_url`
*(as of v3.0)*| OPTIONAL | Array<Localized String> | A fully qualified URL pointing to the privacy policy for the service. `privacy_last_updated`
*(added in v2.3)* | REQUIRED | Date | The date that the privacy policy provided at `privacy_url` was last updated. `rental_apps` | OPTIONAL | Object | Contains rental app information in the `android` and `ios` JSON objects. `rental_apps.android` | OPTIONAL | Object | Contains rental app download and app discovery information for the Android platform in the `store_uri` and `discovery_uri` fields. See [examples](#deep-links-examples) of how to use these fields and [supported analytics](#analytics). `rental_apps.android.store_uri` | REQUIRED | URI | URI where the rental Android app can be downloaded from. Typically this will be a URI to an app store, such as Google Play. If the URI points to an app store, the URI SHOULD follow Android best practices so the viewing app can directly open the URI to the native app store app instead of a website.

See the [Analytics](#analytics) section for how viewing apps can report the origin of the deep link to rental apps.

Example value: `https://play.google.com/store/apps/details?id=com.example.android` `rental_apps.android.discovery_uri` | REQUIRED | URI | URI that can be used to discover if the rental Android app is installed on the device (for example, using [`PackageManager.queryIntentActivities()`](https://developer.android.com/reference/android/content/pm/PackageManager.html#queryIntentActivities)). This intent is used by viewing apps to prioritize rental apps for a particular user based on whether they already have a particular rental app installed.

Example value: `com.example.android://` `rental_apps.ios` | OPTIONAL | Object | Contains rental information for the iOS platform in the `store_uri` and `discovery_uri` fields. See [examples](#deep-links-examples) of how to use these fields and [supported analytics](#analytics). `rental_apps.ios.store_uri` | REQUIRED | URI | URI where the rental iOS app can be downloaded from. Typically this will be a URI to an app store, such as the Apple App Store. If the URI points to an app store, the URI SHOULD follow iOS best practices so the viewing app can directly open the URI to the native app store app instead of a website.

See the [Analytics](#analytics) section for how viewing apps can report the origin of the deep link to rental apps.

Example value: `https://apps.apple.com/app/apple-store/id123456789` `rental_apps.ios.discovery_uri` | REQUIRED | URI | URI that can be used to discover if the rental iOS app is installed on the device (for example, using [`UIApplication canOpenURL:`](https://developer.apple.com/documentation/uikit/uiapplication/1622952-canopenurl?language=objc)). This intent is used by viewing apps to prioritize rental apps for a particular user based on whether they already have a particular rental app installed.

Example value: `com.example.ios://` **Example:** ```json { "last_updated": "2023-07-17T13:34:13+02:00", "ttl": 1800, "version": "3.1-RC", "data": { "system_id": "example_cityname", "languages": ["en"], "name": [ { "text": "Example Bike Rental", "language": "en" } ], "short_name": [ { "text": "Example Bike", "language": "en" } ], "operator": [ { "text": "Example Sharing, Inc", "language": "en" } ], "opening_hours": "Apr 1-Nov 3 00:00-24:00", "start_date": "2010-06-10", "url": "https://www.example.com", "purchase_url": "https://www.example.com", "phone_number": "+18005551234", "email": "customerservice@example.com", "feed_contact_email": "datafeed@example.com", "timezone": "America/Chicago", "license_url": "https://www.example.com/data-license.html", "terms_url": [ { "text": "https://www.example.com/en/terms", "language": "en" } ], "terms_last_updated": "2021-06-21", "privacy_url": [ { "text": "https://www.example.com/en/privacy-policy", "language": "en" } ], "privacy_last_updated": "2019-01-13", "rental_apps": { "android": { "discovery_uri": "com.example.android://", "store_uri": "https://play.google.com/store/apps/details?id=com.example.android" }, "ios": { "store_uri": "https://apps.apple.com/app/apple-store/id123456789", "discovery_uri": "com.example.ios://" } }, "brand_assets": { "brand_last_modified": "2021-06-15", "brand_image_url": "https://www.example.com/assets/brand_image.svg", "brand_image_url_dark": "https://www.example.com/assets/brand_image_dark.svg", "color": "#C2D32C", "brand_terms_url": "https://www.example.com/assets/brand.pdf" } } } ``` ### vehicle_types.json *(added in v2.1)* REQUIRED of systems that include information about vehicle types in the `vehicle_status.json` file. If this file is not included, then all vehicles in the feed are assumed to be non-motorized bicycles. This file SHOULD be published by systems offering multiple vehicle types for rental, for example pedal bikes and ebikes.
The following fields are all attributes within the main `data` object for this feed. Field Name | REQUIRED | Type | Defines ---|---|---|--- `vehicle_types` | Yes | Array<Object> | Contains one object per vehicle type. `vehicle_types[].vehicle_type_id` | Yes | ID | Unique identifier of a vehicle type. See [Field Types](#field-types) above for ID field requirements. `vehicle_types[].form_factor` | Yes | Enum | The vehicle's general form factor.

Current valid values are:
`vehicle_types[].rider_capacity`
*(added in v2.3)* | OPTIONAL | Non-negative integer | The number of riders (driver included) the vehicle can legally accommodate. `vehicle_types[].cargo_volume_capacity`
*(added in v2.3)* | OPTIONAL | Non-negative integer | Cargo volume available in the vehicle, expressed in liters. For cars, it corresponds to the space between the boot floor, including the storage under the hatch, to the rear shelf in the trunk. `vehicle_types[].cargo_load_capacity`
*(added in v2.3)* | OPTIONAL | Non-negative integer | The capacity of the vehicle cargo space (excluding passengers), expressed in kilograms. `vehicle_types[].propulsion_type` | Yes | Enum | The primary propulsion type of the vehicle.

Current valid values are:
This field was inspired by, but differs from the propulsion types field described in the [Open Mobility Foundation Mobility Data Specification](https://github.com/openmobilityfoundation/mobility-data-specification/blob/main/general-information.md#propulsion-types). `vehicle_types[].eco_labels`
*(as of v3.0)* | OPTIONAL | Array<Object> | Vehicle air quality certificate. Official anti-pollution certificate, based on the information on the vehicle's registration certificate, attesting to its level of pollutant emissions based on a defined standard. In Europe, for example, it is the European emission standard. The aim of this measure is to encourage the use of the least polluting vehicles by allowing them to drive during pollution peaks or in low emission zones. `vehicle_types[].eco_labels[].country_code`
*(added in v2.3)*| REQUIRED | Country code | Country where the `eco_sticker` applies. `vehicle_types[].eco_labels[].eco_sticker`
*(added in v2.3)* | REQUIRED | String | Name of the eco label. The name must be written in lowercase, separated by an underscore.

Example of `eco_sticker` in Europe : `vehicle_types[].max_range_meters` | Conditionally REQUIRED | Non-negative float | If the vehicle has a motor (as indicated by having a value other than `human` in the `propulsion_type` field), this field is REQUIRED. This represents the furthest distance in meters that the vehicle can travel without recharging or refueling when it has the maximum amount of energy potential (for example, a full battery or full tank of gas). `vehicle_types[].name`
*(as of v3.0)* | OPTIONAL | Array<Localized String> | The public name of this vehicle type. `vehicle_types[].vehicle_accessories`
*(added in v2.3)* | OPTIONAL | Array<String> | Description of accessories available in the vehicle. These accessories are part of the vehicle and are not supposed to change frequently. Current valid values are: `vehicle_types[].g_CO2_km`
*(added in v2.3)* | OPTIONAL | Non-negative integer | Maximum quantity of CO2, in grams, emitted per kilometer, according to the [WLTP](https://en.wikipedia.org/wiki/Worldwide_Harmonised_Light_Vehicles_Test_Procedure). `vehicle_types[].vehicle_image`
*(added in v2.3)* | OPTIONAL | URL | URL to an image that would assist the user in identifying the vehicle (for example, an image of the vehicle or a logo).
Allowed formats: JPEG, PNG. `vehicle_types[].make`
*(as of v3.0)* | OPTIONAL| Array<Localized String> | The name of the vehicle manufacturer.

Example: `vehicle_types[].model`
*(as of v3.0)* | OPTIONAL| Array<Localized String> | The name of the vehicle model.

Example `vehicle_types[].color`
*(added in v2.3)*| OPTIONAL| String| The color of the vehicle.

All words must be in lower case, without special characters, quotation marks, hyphens, underscores, commas, or dots. Spaces are allowed in case of a compound name.

Example `vehicle_types[].description`
*(added in v3.0)*| OPTIONAL | Array<Localized String> | Customer-readable description of the vehicle type outlining special features or how-tos. `vehicle_types[].wheel_count`
*(added in v2.3)* | OPTIONAL | Non-negative Integer | Number of wheels this vehicle type has. `vehicle_types[].max_permitted_speed`
*(added in v2.3)* | OPTIONAL | Non-negative Integer | The maximum speed in kilometers per hour this vehicle is permitted to reach in accordance with local permit and regulations. `vehicle_types[].rated_power`
*(added in v2.3)* | OPTIONAL | Non-negative Integer | The rated power of the motor for this vehicle type in watts. `vehicle_types[].default_reserve_time`
*(added in v2.3)* | Conditionally REQUIRED | Non-negative Integer | REQUIRED if `reservation_price_per_min` or `reservation_price_flat_rate` are defined. Maximum time in minutes that a vehicle can be reserved before a rental begins. When a vehicle is reserved by a user, the vehicle remains locked until the rental begins. During this time the vehicle is unavailable and cannot be reserved or rented by other users. The vehicle status in `vehicle_status.json` MUST be set to `is_reserved = true`. If the value of `default_reserve_time` elapses without a rental beginning, the vehicle status MUST change to `is_reserved = false`. If `default_reserve_time` is set to `0`, the vehicle type cannot be reserved. `vehicle_types[].return_constraint`
*(as of v2.3)*| OPTIONAL | Enum | The conditions for returning the vehicle at the end of the rental.

Current valid values are: