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

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.

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.

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 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. 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, 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. 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, 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, 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.

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 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: 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 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.