Micromobility Data Platforms and Fleet Management APIs

Two open standards do most of the structural heavy lifting here: GBFS and MDS. They are not interchangeable, and conflating them is one of the more common mistakes I see from operators who are new to the space.

GBFS (General Bikeshare Feed Specification) was adopted in 2015 and is managed by MobilityData. It is the public-facing standard. Its job is to let consumer apps, transit platforms, and feed aggregators display real-time vehicle availability. When you open Google Maps and see a Lime scooter nearby, that pin comes from a GBFS feed. GBFS v3.0 requires dockless vehicle status updates within five minutes. Not a suggestion. Real-time accuracy is baked into the spec.

MDS (Mobility Data Specification) originated at the Los Angeles Department of Transportation in 2018 and is now governed by the Open Mobility Foundation. MDS is the regulatory standard. It is not public. It gives cities access to historical trip records — origin, destination, duration, distance, cost — and real-time vehicle positions. More than 130 regulatory agencies worldwide now require MDS compliance as a permit condition. You show up with it or you do not show up at all.

What makes MDS genuinely interesting is that it is not just a reporting channel. Cities can push policy downstream through it: speed limits, parking rules, and fleet size caps delivered as machine-readable instructions via the MDS Policy API, not PDFs sitting in someone's inbox. I remember when enforcement basically meant a city planner emailing a spreadsheet and hoping someone on the operator side read it before Monday. MDS made that whole dynamic obsolete.

One thing worth keeping straight: all MDS-compatible feeds must also expose a public GBFS feed. The two standards are linked. GBFS is what the public consumes. MDS is what regulators enforce with. Same vehicle data, different audiences, different access controls.

What the IoT and Telematics Layer Actually Does Inside Each Vehicle

Before any of the platform-level stuff matters, something has to generate the data. That something is the IoT module inside each vehicle, and it does more than most people expect.

Every scooter or e-bike carries an IoT module connected to the cloud over cellular, typically using LTE-M or NB-IoT for low-power fleet communication. It is constantly transmitting location, speed, battery status, and lock state. When a rider unlocks a vehicle, that command travels the same channel in reverse: rider request to cloud to IoT module to electronic lock release. The latency on that round trip is a direct product experience issue. A slow unlock is not an engineering footnote. It is the first thing a rider notices, and it colors everything that follows.

That same channel handles a lot more than unlocking:

• Over-the-air (OTA) firmware updates
• Geofenced speed reduction when a vehicle enters a designated slow zone
• Remote lock activation if someone tampers with the vehicle
• Sound alarms

Battery telemetry does double duty. It feeds the rider-facing app with a range estimate, and it feeds the operator dashboard with a signal about which vehicles need field charging or a battery swap. Fleet management and tracking systems make up the largest segment in the micromobility integration systems market, valued at USD 629.2 million in 2024. That number reflects how central this layer is to what operators actually spend money on.

The IoT module is where every data stream originates. Its reliability sets a ceiling on everything downstream. When a module goes flaky — which happens, hardware in the field takes abuse — the failures ripple upward in ways that are not always obvious until something breaks at exactly the wrong moment.

How Fleet Management Platforms Turn Raw Telemetry Into an Operator's Daily Reality

Raw telemetry from 35,000 vehicles is not useful on its own. Fleet management platforms are what make it actionable. Think of them as the operating system for the fleet.

Core capabilities any serious platform provides:

• A real-time map of all vehicles with live status
• An admin dashboard for pricing configuration (per-minute rates, unlock fees, subscriptions, corporate packages, promo codes)
• Trip history and financial reporting
• User management

Geofencing and zone management via a dedicated geofencing API deserves special attention because it is not optional. It is how operators enforce city-issued operational boundaries, parking zones, no-go areas, and speed corridors. Compliance lives or dies on this capability. Skip it and you are not just cutting corners operationally. You are putting your permit at risk, and permits are harder to get back than they are to lose.

Cloud deployment dominates this layer, holding 45% market share in 2024 and growing at 17% CAGR through 2034, hosted on infrastructure like AWS, Azure, or GCP. Most operators are not running their own server racks. They are running on cloud platforms, which shifts their concerns toward API reliability and vendor relationships rather than physical infrastructure.

The vendor landscape is still fragmented but consolidating. ATOM Mobility bills itself as the largest B2B SaaS platform in the space, with over 200 projects across more than 140 cities in 60-plus countries, managing 35,000-plus vehicles and over a million rides monthly. They acquired ScootAPI in June 2025. Joyride takes a different approach, bundling IoT connectivity, consumer app, operator app, backend management, and payment infrastructure into one stack, absorbing adjacent functionality rather than leaving it to point integrations. Ridecell reached $31.5 million in revenue in 2024. The top five platforms collectively held 43% of market share in 2024, which means the remaining 57% is spread across a long tail of smaller players. Consolidation is happening, but anyone who tells you it is finished is getting ahead of themselves.

How Cities Actually Enforce the Rules (It Is Not Inspectors With Clipboards)

Cities have gotten serious about micromobility as managed public infrastructure. Permits now routinely include data-sharing requirements, parking enforcement mandates, and fleet size caps enforced via API. The enforcement mechanism is the platform, not the person.

Long Beach's 2025 shared micromobility permit explicitly authorizes a third-party platform to supply real-time data for tracking fleet operations and compliance. The regulator is not just receiving data. It is procuring the platform that ingests it. That is a fundamentally different relationship than a city asking for monthly PDF reports, and operators who have not noticed that shift are often the ones getting surprised at permit renewal.

Digital enforcement has enabled specific, concrete actions:

• Berlin capped e-scooters within its light rail circle at 19,000 vehicles, enforced from January 2024 through March 2025
• Madrid and Barcelona have fleet caps and designated parking zones enforced through data feeds
• Paris banned shared e-scooters outright in 2023

None of these are managed through manual inspection. They run through MDS policy feeds.

On parking enforcement and curb management specifically, NABSA's 2024 data shows 69% of systems use virtual geofenced zones, 63% use designated physical areas, and 18% require riders to lock to physical infrastructure. Each approach maps to specific platform and API capabilities operators have to support. You cannot pick one and ignore the others if different cities you operate in use different methods.

Fluctuo aggregates data from 100 operators across 400-plus cities into a single dashboard, which illustrates how third-party compliance and analytics platforms sit between raw MDS feeds and the reporting that planners and regulators actually use day to day.

The practical reality for operators: entering a new city means integrating with whichever compliance platform or MDS pipeline that city has procured. Sometimes that information is easy to find. Often it is not, and you end up on a call with a city IT contact who is not entirely sure either. I have been on more than one of those calls.

How AI and Rebalancing Algorithms Turn Trip Data Into Logistics Decisions

The core rebalancing problem is simple to describe and genuinely annoying to solve. Vehicles cluster where trips end, not where demand will next appear. Everyone in a neighborhood commutes downtown at 9am and locks up near the train station. By mid-morning, all your scooters are downtown. The neighborhood is empty. That is lost revenue and a frustrated rider who opens the app, sees nothing nearby, and closes it.

AI-driven rebalancing attacks this proactively rather than reactively. Platforms use historical trip origin and destination data, time-of-day patterns, event calendars, and weather data for demand forecasting, then dispatch field teams accordingly. The goal is turning reactive repositioning into scheduled logistics. Think of it the way a delivery company routes its trucks the night before rather than improvising at dawn.

Vulog's AiMA platform does predictive pricing and fleet optimization developed over 15-plus years. Their client list includes Volkswagen, Kia, and Stellantis. When OEM-level operators treat AI optimization as a standard feature rather than a differentiator, the technology has crossed a threshold. It is expected now, not a premium add-on.

The AI pipeline is broader than rebalancing alone. Damage detection via computer vision (riders submit photos at trip end), predictive maintenance via IoT telemetry (battery cycle counts, motor anomalies). These increasingly run through the same data infrastructure as rebalancing, which is efficient until data quality slips and suddenly every downstream system is making bad calls at once. That kind of cascading failure is harder to diagnose than a single broken component.

Research supports the power of the public data layer here. A study of 29 German cities ingesting open GBFS feeds from Dott, Bolt, Voi, and Lime found that 41 days of public GBFS data could replace proprietary MDS trip records for hotspot detection with 95.5% accuracy. The public data layer alone is rich enough to support meaningful demand modeling, which has real implications for third-party analytics tools building on top of standard feeds.

How Third-Party Integrations Connect Fleets to the Rest of Urban Mobility

A scooter or e-bike is rarely someone's whole trip. NABSA's 2024 data is clear on this: 74% of riders use shared micromobility to connect to transit. The vehicle is the first mile or the last mile. That means the platform has to fit into a larger mobility ecosystem, and operators who treat their fleet as a standalone product tend to discover that discovery is a bigger problem than they expected.

GBFS is the mechanism that makes that fit possible. Transit apps including Google Maps, Apple Maps, Citymapper, and Transit ingest GBFS feeds to show vehicle availability alongside bus and rail options, enabling multimodal trip planning in a single interface. Without a clean GBFS implementation, a fleet is invisible to the apps riders actually use to plan trips. That is a ridership problem, not a technical footnote.

Payment integrations matter just as much. Platforms have to connect to payment processors, mobile wallets, and in some markets transit fare systems. Joyride's explicit inclusion of fintech infrastructure in its core stack reflects how central payment API reliability is to operator revenue. A failed payment is a lost ride, a frustrated user, and a support ticket someone has to handle.

Corporate and university programs add another layer of complexity. These use cases require SSO, HR system integrations, and invoicing APIs. The B2B deployment demands API extensibility well beyond the core consumer flow.

The integration surface keeps growing as operators enter new markets. Each city may use different compliance platforms, parking enforcement systems, and transit data providers. Operators who build direct integrations for each one face compounding maintenance burden as third-party APIs change. Pre-built connectors to common transit, payment, and city-data APIs can reduce the engineering cost of launching in a new city from months to days. That timeline difference matters a lot when you are racing a competitor into the same market, which you almost always are.

What All of This Means for Scale — And Where the Friction Still Bites

The micromobility platform market was valued at USD 8 billion in 2025, projected to reach USD 24 billion by 2036 at a 10.6% CAGR. The software and integration layer is itself a large and growing market, not just a cost center for operators.

Standardization around MDS and GBFS has genuinely lowered the floor. An operator can enter a new city without negotiating bespoke data formats because both sides share a common protocol. That was not always the case. People who were in the room when cities were demanding custom CSV exports emailed every Monday know the difference is enormous.

But the friction that remains is real, and it shows up in specific places:

• MDS versions differ across cities. Compliance with one city's implementation does not guarantee smooth compliance with another's.
• GBFS adoption varies internationally. The standard is not universally applied at the same version level everywhere.
• Every platform vendor exposes proprietary APIs for features beyond the standard: maintenance workflows, rebalancing tools, pricing engines. Operators face integration work at every boundary.

Fleet scale pressure is growing alongside those friction points. E-bike trips nearly tripled from 2019 to 2024 in North America. The data volumes and API call rates involved are growing faster than many operators' internal infrastructure teams can handle, and that gap tends to become visible at the worst possible moment.

The market is moving toward platforms absorbing more of the integration burden. ATOM's acquisition of ScootAPI and Autofleet's acquisition by Element Fleet Management for $110 million in August 2024 both point in the same direction: consolidation that reduces fragmentation, but also raises switching costs for operators who get deep into a particular stack. That trade-off is real and not always visible until it is too late to unwind.

The practical question for any operator is less "should we build or buy" and more "which integrations can we delegate to managed infrastructure and which require proprietary control." Get that call wrong in either direction and you either over-invest in building something a platform would have handled, or you hand over control of something that turns out to matter competitively. Neither mistake is cheap, and I have watched companies make both.

The layered architecture exists because the problem is genuinely hard. Three audiences, one vehicle, continuous data, real-time enforcement, and city-by-city variation in how rules are written and applied. The platforms that make this work are the reason 333,000 vehicles across 415 cities can operate as a coherent system at all.