GBFS and MDS Explained: Open Mobility Data for Operators

GBFS (General Bikeshare Feed Specification) is an open, public, real-time feed that shows where shared vehicles and stations are and whether each vehicle can be rented right now; trip planners and map apps read it. MDS (Mobility Data Specification) is a data standard cities use to receive trip and vehicle status data from operators, for permits, oversight and planning. Put simply, GBFS tells the public what is available now, and MDS tells the city what happened on its streets.

If you run shared scooters, bikes or mopeds, you will probably be asked for one or both, often just before a permit application. This guide explains what each contains, who reads it, how they differ, what they mean for rider privacy and how to get ready.

What is GBFS?

GBFS is an open standard for publishing the live state of a shared vehicle system: which vehicles and stations exist, where they are and whether they can be rented.

It started with docked bike share, which explains the name, and now also describes dockless bikes, e-scooters, mopeds and cars. It is maintained by MobilityData, a non-profit organisation, with input from operators, cities and app makers.

A GBFS feed is a set of small JSON files at public web addresses, updated constantly by the operator’s system. One starting file lists all the others, so an app needs only a single address to find the rest. Each file says when it was last updated and how long its data stays fresh, so apps know when to check again.

GBFS is read-only. Nobody books, unlocks or pays through the feed. When a rider taps a vehicle in a map app, the app hands them over to the operator’s own app to rent it.

What does a GBFS feed contain?

• System information: the operator and service name, time zone, language, contact details and links to the rider app.
• Vehicle types: the kinds of vehicles in the system, such as pedal bikes, e-bikes or e-scooters, and how far an electric one can travel on a full charge.
• Station information and status: for station-based systems, where each station is, how many docks it has, and how many vehicles and free docks it has right now.
• Vehicle status: for free-floating systems, the location of each vehicle available to rent, whether it is reserved or out of service, and its remaining range.
• Pricing plans: what a ride costs, such as an unlock fee plus a price per minute or per kilometre.
• Geofencing zones: areas with rules, such as where riding is not allowed, where a ride cannot end and where a lower speed limit applies.
• Alerts: notices about station closures, service changes or disruption.

Not every system publishes every file. A docked bike system needs station files; a free-floating scooter fleet needs vehicle status. Prices and zones are not always required, but they make the feed far more useful to apps and cities.

Who reads a GBFS feed?

• Journey planners and map apps show nearby vehicles next to buses and trains, so a rider can plan a trip that ends on a scooter or bike.
• Cities and transport agencies get a quick public view of how many vehicles are out and where.
• Researchers and advocacy groups study availability, coverage and how shared vehicles connect with public transport.
• Developers build dashboards, accessibility tools and local travel apps.

For an operator, a good feed is free distribution. Every app that reads it can send riders your way.

What is MDS (Mobility Data Specification)?

MDS is an open data standard that lets cities receive data from shared mobility operators, and publish rules back to them, in one format every operator can use.

It is maintained by the Open Mobility Foundation, a non-profit organisation. It began with dockless scooters and bikes, and has since grown to cover other modes, such as car share.

Where GBFS shows what is available right now, MDS shows what happened: every trip and every change in a vehicle’s state. Access is private. Only the city agency, or a data platform working on its behalf, receives credentials.

Data can move in two directions. In one setup, the operator runs an interface the city pulls data from. In another, the operator pushes data to the city in close to real time as things happen. The city decides which it wants, so read the permit terms carefully.

What data does MDS cover?

• Vehicles: the list of vehicles in the fleet, with their type and how they are powered.
• Trips: when and where each trip started and ended, its route, duration, distance and often its cost.
• Vehicle status changes (events): each time a vehicle becomes available, is reserved, starts or ends a trip, runs low on battery, is taken for repair, is moved by staff or leaves the service area.
• Telemetry: location points reported by vehicles, mainly during trips.
• Policies (published by the city): rules such as fleet caps, speed limits, parking rules and areas where riding is not allowed.
• Geographies (published by the city): the named areas those rules refer to, such as the permit boundary, districts and parking zones.

Why do cities ask for MDS?

• Permits: to check that each operator meets its permit terms, and to inform decisions at the next permit round.
• Fleet caps: to count how many vehicles each operator has on the street against its limit.
• Parking and no-ride zones: to see where trips end and whether vehicles are ridden or left where they should not be.
• Equity: to confirm vehicles are placed across every area the permit covers, not only the busiest streets.
• Safety: to set trip volumes and routes alongside incident reports and find risky locations.
• Planning: to see where people actually ride, which helps decide where bike lanes and parking should go.

What is the difference between GBFS and MDS?

The short version: GBFS is a public shop window, and MDS is a private report to the regulator. Operators under a city permit are often asked for both.

The two work well together. A city can use your GBFS feed for a quick public count and MDS for the detail. Because both describe the same vehicles, a city will notice when they disagree.

Do GBFS and MDS expose rider data?

Neither should reveal who rode, but they handle privacy differently, because one is public and one is not. What follows is general guidance, not legal advice.

GBFS: public, so it must stay anonymous

A GBFS feed should never contain anything that points to an individual rider: no names, accounts, phone numbers or trip histories. The standard helps here. Vehicles on a ride are left out of the vehicle list, and vehicle IDs in the public feed change after each trip, so nobody can follow one vehicle from ride to ride and work out where a person went. Check that your own feed does this, including any extra fields you add.

MDS: private, but still sensitive

MDS does not ask for rider names or accounts. Trip data is still sensitive, because start and end points, times and routes can reveal where someone lives or works when combined with other information. Before any data flows, cities and operators should agree on:

• Access: which people and systems may read the data, and how their keys are issued and withdrawn.
• Security: encrypted connections, strong authentication and a record of who accessed what.
• Retention: how long raw trip data is kept before it is deleted or reduced to totals.
• Use: what the data may be used for, and whether it may be passed to anyone else.
• Aggregation: sharing totals and heat maps instead of single trips wherever that is enough.

Where data protection laws apply, such as the GDPR in the EU, trip locations may count as personal data, so both sides should check their obligations before sharing.

How do operators get ready for GBFS and MDS?

A feed is only as good as the fleet data behind it. Many problems a city or app spots come from that data, not from the file format.

1. Keep vehicle status accurate. A vehicle shown as available must be rentable. Take broken, flat or missing vehicles out of service straight away, and make sure trips are recorded correctly even when signal drops. Reliable connected devices that report position, battery and faults are the base of every feed.
2. Define zones clearly. Draw no-ride, no-parking and slow zones once, and use the same shapes in the rider app, on the vehicle and in your feeds. Our guide to smart geofence control covers zone types and rules.
3. Match city geographies. When a city publishes its boundaries and zones, import them as published instead of redrawing them by hand, so your data and the city’s refer to the same areas.
4. Confirm exactly what the city asks for. Both standards have evolved through several versions. Ask which version, which parts, whether the city pulls data or you push it, how access is secured and by what date.
5. Test feeds before a permit deadline. Run your GBFS feed through an open validator, compare its vehicle counts with your live map, and send the city sample MDS data early, while there is still time to fix problems.
6. Watch uptime and freshness. Check that feeds respond and that their timestamps keep moving. A feed that stops updating shows riders vehicles that are no longer there, and a gap in MDS data can look like a missed permit condition.
7. Keep one source of truth. Feeds built from a separate export or spreadsheet drift away from what your team sees. When you compare platforms, ask where the feeds come from; it belongs on the list in our guide on how to choose scooter sharing software.

How does Axons Mobility help with GBFS and MDS?

Axons Mobility publishes GBFS feeds and provides MDS data for cities from the same live data that runs the operator console. What riders see in map apps, what the city receives and what your team works from all describe the same vehicles, zones and trips, so availability and trip records stay consistent. Operators can share the GBFS feed with journey planners and provide MDS data to city regulators when they apply for permits. See Axons Mobility integrations for how feeds fit with the rest of your tools.

The simplest way to judge whether your fleet data is ready for a city is to watch it on real rides. Axons Mobility offers a free 15-day trial on your own vehicles, so you can see vehicle status, zones and trips working together in the console and review the integrations you will need before your next permit application.