# MDS, GBFS, and CDS: the shared-mobility data stack, mapped

> Three specifications cover the same scooters, bikes, and delivery vans, and practitioners routinely pick the wrong one. Here is what each was built to answer, why MDS requires a public GBFS feed, and where the boundary between them actually falls.

Published 2026-07-31 by Nick Sawinyh.
Explainer in Feeds & Standards.
Canonical: https://its-feed.com/articles/shared-mobility-data-stack/
Keywords: mobility data specification, mds vs gbfs, curb data specification, gbfs, shared mobility data standards

---

A city that wants to regulate scooters, a rider who wants to find one, and a
delivery company that wants to park legally are all describing the same vehicle
on the same street. There are three open specifications covering that ground, and
teams pick the wrong one often enough that the two governing bodies maintain [a
joint document explaining the
difference](https://github.com/openmobilityfoundation/governance/blob/main/technical/GBFS_and_MDS.md).

The short version is that the three specs are not competitors and not layers of a
stack in the usual sense. Each one connects a different pair of parties and
answers a different question. GBFS answers what a rider can rent right now. MDS
answers what an operator's fleet did in a city. CDS answers who may use a stretch
of curb and who actually did.

![Diagram of three specifications. GBFS, stewarded by MobilityData, answers 'what can I rent right now', flowing one way from operator to riders, trip planners, and aggregators; it is public with no key. MDS, stewarded by the Open Mobility Foundation, answers 'what did your fleet do in my city', flowing both ways between operator and city regulator; it is authenticated with Policy endpoints public. CDS, also stewarded by the Open Mobility Foundation, answers 'who may use this curb, and who did', flowing both ways between a city and delivery and fleet operators; curbs are public and events are authenticated.](https://its-feed.com/charts/shared-mobility-data-stack-map.png)

*The useful question is not what each spec contains but who sits on either end of it. Two of the three carry data a city cannot publish as it arrives. Source: Specification repositories and the joint OMF and MobilityData comparison document, read 2026-07-31.*

## The line that matters is vehicle identity

Set the GBFS and MDS descriptions of the same scooter side by side and one
difference does more work than the rest.

GBFS requires that the `vehicle_id` be rotated to a random string after each trip,
and [the spec](https://github.com/MobilityData/gbfs/blob/v3.0/gbfs.md) says plainly
that persistent vehicle IDs are a threat to user privacy. Read the public
feed all day and you cannot tell whether the scooter at the corner this afternoon
is the one that was there this morning. That is deliberate. Without it, anyone
polling a public feed could reconstruct trips by watching a vehicle disappear in
one place and reappear in another.

MDS does the opposite and keeps the vehicle identifier stable. This is also
deliberate, because a regulator checking whether an operator honored a permit cap
or cleared a no-parking zone needs to follow individual vehicles over time. The
regulator's job is exactly the linkage the public feed is designed to prevent.

Everything else follows from that. GBFS states its design goals as providing the
status of the system at this moment and deliberately not providing information
whose primary purpose is historical. It covers vehicles currently available for
rent or disabled, with three states and no concept of an event. MDS covers every
vehicle deployed in the right of way, including ones on trips and ones outside the
jurisdiction, and version 2.0 defined nine vehicle states and 47 event types. One
spec is a snapshot for travelers. The other is an audit trail for a regulator.

| | GBFS | MDS | CDS |
|---|---|---|---|
| Steward | MobilityData | Open Mobility Foundation | Open Mobility Foundation |
| Subject | Vehicles available to rent | All deployed vehicles | Curb space and curb activity |
| Read by | Anyone | Regulators | Cities and permitted curb users |
| Vehicle identity | Randomized every trip | Stable | Vehicle properties, no rider link |
| History | Out of scope by design | Trips and events retained | Historic events and metrics |
| Access | Public, unauthenticated | Authenticated, except Policy, Geography, and Jurisdiction | Curbs public, events authenticated |
| Current version | 3.0, April 2024 | 2.1.0, July 2026 | 1.1.0, October 2025 |

Anyone who assumes the two specs compete tends to miss the detail that settles it.
MDS has [required a public `gbfs.json` since version
0.3.0](https://github.com/openmobilityfoundation/mobility-data-specification/blob/main/general-information.md).
An operator complying with a city's MDS requirement is also publishing a GBFS feed
that anybody can read. The regulatory interface sits on top of the public one
rather than replacing it, and a city that mandates MDS gets a rider-facing feed as
a side effect. That is worth knowing before an agency writes a permit condition
asking for one or the other.

## MDS in practice

MDS is six APIs, and the split between them is more interesting than the list. The
Provider and Agency APIs carry the sensitive material, moving vehicle and trip
records between an operator and a city, and both are authenticated. Provider has
the city pulling data from the operator; Agency has the operator pushing events to
the city as they happen. They are alternative directions for the same exchange
rather than two things to implement at once.

The other four go the other direction. Policy publishes the rules a city is
imposing, such as caps, speed limits, and geofenced no-ride areas. Geography
publishes the boundaries those rules apply to. Jurisdiction lets neighboring
agencies tell each other and operators where one city's authority ends. Metrics
defines a shared vocabulary for aggregate measures so two cities count the same
thing the same way. The specification requires that Policy, Geography, and
Jurisdiction be served unauthenticated and public, on the reasoning that a city
imposing digital rules should be publicly accountable for them and third parties
should be able to build on them.

That requirement gets less attention than it deserves. It means the regulatory
half of MDS is legible to anyone: you can read what a city is actually enforcing
without a data-sharing agreement. OMF says [more than 70 agencies are publishing
real-time rules and geofencing through MDS
Policy](https://www.openmobilityfoundation.org/mds-users/), out of more than 1,200
cities and public agencies where operators use MDS at all, and more than 200
mobility service providers on the other side of the exchange. Those figures come
from OMF and carry no date, and they count different things, so treat them as
orders of magnitude rather than a census. The joint comparison document maintained
by OMF and MobilityData puts the count of regulators that actually require MDS at
more than 130, which is the narrower and more meaningful number.

Version 2.1.0 landed on July 9, 2026 and was [announced on July
20](https://www.openmobilityfoundation.org/mds-new-tools-for-safer-streets/).
Under the project's own versioning it is a minor release, meaning nothing in 2.x
breaks, which undersells how much it takes on. The modes overhaul brings
delivery, including sidewalk robots and gig deliveries, fixed-route bus and shuttle
operations that connect to GTFS trips and stops, city fleet vehicles, and for-hire
autonomous services. A new endpoint captures incidents and crashes, covering
unplanned stops, remote takeovers, autonomous system disengagement, tip-overs,
harsh braking, near misses, vandalism, and theft.

Read that list next to the spec's origins and the trajectory is clear. MDS was
built to count scooters. It is now positioned as the general interface between a
city and anything moving in its right of way, robotaxis included. Whether cities
have the capacity to consume that much surface area is a separate question. The
130-plus figure above counts agencies requiring data from micromobility operators
specifically, which suggests the installed base is still mostly doing what the
spec was originally for.

## Why the public-private line is drawn where it is

The reason MDS data is not simply published is that trip records are sensitive
even without a name attached. The guidance from the two governing bodies is blunt
about it: because MDS feeds include deidentified data about individual trips, they
should never be made public without redaction or aggregation.

This is not a hypothetical concern, and it has been litigated. In June 2020 two
riders sued the Los Angeles Department of Transportation over its requirement that
scooter companies hand over MDS data, arguing the collection was an unreasonable
search. The Ninth Circuit [affirmed the dismissal of the case in May
2022](https://cdn.ca9.uscourts.gov/datastore/opinions/2022/05/23/21-55285.pdf),
holding that the rider had no reasonable expectation of privacy in the data the
city collected. LADOT's program stood.

The outcome settled whether the collection could proceed. It did not make the
underlying data less re-identifiable, and the technical objection the plaintiffs
and their supporters raised is the same one that shapes the specs today:
fine-grained location traces are hard to anonymize, because a small number of
points is often enough to pick one person out of a crowd. Location data resists
being made safe by stripping names off it. That is why the boundary between GBFS
and MDS is drawn at
identity rather than at content, and why an agency that publishes MDS extracts as
open data has to aggregate first.

## GBFS in practice, and the version problem

GBFS is the oldest of the three and the one an operator is most likely to be
publishing already. It is a set of JSON
files an operator publishes at a discoverable URL, starting with `gbfs.json`, which
points to the rest: system information, station status for docked systems, vehicle
status for free-floating ones, pricing plans, alerts, and geofencing zones. Trip
planners and aggregator apps read those files, which is how a rider sees bikes from
three different operators in one map.

The change process is deliberately constrained. Changes need at least three votes
not counting the author, and the votes must include both a producer and a consumer
of the data, so neither operators nor app developers can carry a change alone.
Versions are supported across no more than two major releases, and older ones are
deprecated 180 days after a new major version becomes official.

That is the spec. The deployed reality is looser. GBFS 3.0
has been the current version since April 2024. To find out how much of the
installed base had actually moved, we took the [MobilityData systems
catalog](https://github.com/MobilityData/gbfs/blob/master/systems.csv), the
community-maintained registry of known public feeds, and requested every feed's
discovery URL to read the version it reports. Of 1,520 catalogued systems, 1,351
answered.

![Stacked bar chart comparing GBFS major version adoption. Of 171 live United States feeds, 13 (8 percent) run version 3.0, 128 (75 percent) run version 2.x, and 30 (18 percent) run the deprecated version 1.x. Of 1,180 live feeds in the rest of the world, 509 (43 percent) run version 3.0, 658 (56 percent) run 2.x, and 13 (1 percent) run 1.x.](https://its-feed.com/charts/shared-mobility-data-stack-gbfs-versions.png)

*US feeds have moved to the current major version at roughly one sixth the rate of feeds elsewhere. Of the 43 live feeds worldwide still on the long-deprecated 1.x, 30 are American. Source: ITS Feed analysis of the MobilityData GBFS systems catalog. Every catalogued discovery URL was requested on 2026-07-31; 1,351 of 1,520 returned parseable JSON. Feeds reporting no version field are counted as 1.0, per the spec.*

The regional split is the finding. Outside the US, 43 percent of live feeds serve
GBFS 3.0. Inside it, 8 percent do, while 18 percent are still on a 1.x release that
has been deprecated since 2024. Thirty of the 43 remaining v1.x feeds worldwide are
in the United States.

Two caveats before that number travels. The catalog is community-maintained and
self-reported, so it is a census of known feeds rather than all feeds, and it will
under-represent operators who never registered. And the 169 systems that did not
respond are excluded rather than assumed; if those skew toward neglected feeds, the
deprecated share is understated rather than overstated.

The catalog itself held up well as a source. Comparing the live version reading
against the catalog's own version column for all 171 reachable US feeds turned up
no mismatches, so the registry is accurate everywhere it can be checked.

The practical consequence lands on whoever consumes the data. Version 3.0 renamed
files and restructured fields, most visibly turning `free_bike_status` into
`vehicle_status`, so an aggregator serving US systems cannot simply implement the
current spec and be done. It has to carry parsers for versions going back years,
which is precisely the tax that a standard is supposed to remove. This is what
happens whenever a spec is cheap to publish and nobody downstream is in a position
to insist on a version.

Meanwhile the spec has kept moving. GBFS 3.1 has been through three release
candidates, the most recent in May 2026, adding forward-looking availability for
systems that let riders reserve in advance, fare capping in pricing plans, and a
recommendation that endpoints respond in under a second. It is not final yet. One
feed in the survey was already serving a release candidate.

## CDS, the newest and smallest

The Curb Data Specification is the youngest of the three and the least deployed.
Its subject is not vehicles but space: which stretches of curb exist, what the
rules are on each, and what happened there.

The Curbs API is how a city publishes its curb zones and the policies attached to
them, which is the part that has to exist before anything else works. Events is how
companies report activity at the curb, whether from their own systems or from
sensors. Metrics defines shared methods for calculating dwell time, occupancy, and
utilization so two cities measuring the same thing get comparable answers.

[Version 1.1](https://github.com/openmobilityfoundation/curb-data-specification)
arrived in October 2025 and reads like a spec absorbing lessons from real pilots.
It added the ability to push events to an agency as they occur rather than waiting
to be polled, payment methods and transaction IDs, enforcement records covering
violations and citations including double parking, confidence levels for vehicle
properties detected by computer vision, and the option to define a curb zone as a
line rather than a polygon, which is closer to how a curb actually is.

OMF [lists eleven agencies as CDS
users](https://www.openmobilityfoundation.org/cds-users/): Seattle, Los Angeles,
San Francisco, Minneapolis, Philadelphia, Washington, Pittsburgh, Miami, San Jose,
San Diego, and Omaha. That is a real deployment base and a small one, and it is
concentrated in cities with dedicated curb programs, several of them funded
through US Department of Transportation SMART grants. Nobody should expect CDS to
arrive in a mid-size city the way GBFS did.

## The specs are learning to point at each other

Both recent releases added the same feature, which is a decent sign of where this
is going. MDS 2.1 added external references so a record can point at data held in
another specification, naming CDS as a target. CDS 1.1 added the same mechanism
aimed at GTFS, GBFS, MDS, and work-zone data, and aligned its vehicle and
propulsion types with the current MDS values. MDS 2.1's fixed-route support links
straight to GTFS trips, stops, and schedules.

The governing bodies have been explicit that this is the plan. There is no
intention to reconcile GBFS and MDS into one specification. Each stays
independently governed for its own purpose, while the two organizations attend
each other's planning calls and look for places to share data models. Cross
references are a lower bar than a unified schema, and given that one spec breaks
the link between a vehicle's trips on purpose while the other preserves it on
purpose, a single schema was never a realistic target anyway.

It does mean the reference material ages. The joint GBFS and MDS comparison is
still the best single explanation of the boundary, and parts of it now trail the
specs it describes, including a scope note calling MDS dockless-only that MDS 2.1
has clearly outgrown. Check version numbers against the repositories rather than
the explainers, this one included.

## What to do with this

For an agency deciding what to ask for, the sequence is fairly settled. Require a
public GBFS feed in every permit, because it costs the operator little, it is what
makes vehicles visible in the apps riders already use, and it gives the public
something to check. Add MDS when there is an actual regulatory question that needs
answering, such as whether caps are being honored or equity distribution
requirements are being met, and when somebody on staff can consume the data.
Reach for CDS when curb management is a program with an owner rather than an
aspiration.

For anyone building on this data, the version survey is the practical warning.
Write for the current spec, but check what the feeds you depend on actually serve
before assuming, especially in the US. A
[multimodal trip planner](https://its-feed.com/articles/mobility-as-a-service/) that has to consume all
of this is implementing three versions of GBFS before it gets to anything else,
and that work is invisible in every architecture diagram anyone will show you.

## Frequently asked questions

### What is the difference between MDS and GBFS?

GBFS is a public feed that tells riders and trip planners what is available to rent right now. MDS is an authenticated interface that tells a city regulator what an operator's whole fleet did, including trips in progress and vehicles not available for rent. GBFS is managed by MobilityData and MDS by the Open Mobility Foundation. They are not alternatives: any operator complying with MDS is also required to publish a public GBFS feed.

### Do I need both MDS and GBFS?

If a city requires MDS, then yes. The MDS specification has required a public gbfs.json since version 0.3.0, so a compliant MDS implementation includes a GBFS feed. The reverse is not true. Plenty of operators publish GBFS in cities that have never asked for MDS.

### What is the Curb Data Specification?

CDS is an Open Mobility Foundation specification for curb space rather than vehicles. It has three APIs: Curbs, where a city publishes what its curb zones are and what the rules are; Events, where companies report activity such as commercial loading; and Metrics, which defines shared methods for measuring dwell time and occupancy. Version 1.1 was released in October 2025.

### Why does GBFS randomize vehicle IDs when MDS does not?

The two specs have different consumers, so they make opposite choices about linkability. GBFS requires the vehicle_id to be rotated to a random string after each trip, which prevents anyone reading the public feed from following a vehicle from one trip to the next. MDS keeps a stable vehicle identifier because auditing a permit requires knowing that the same scooter was in the same place all week.

---

Source: ITS Feed, https://its-feed.com/articles/shared-mobility-data-stack/
ITS Feed is an independent editorial site on the data and technology layer of transportation, published by the team at Veodyn. Figures trace to the sources linked inline.
Site index for agents: https://its-feed.com/llms.txt