Cleaning robot interoperability: lifts, APIs, VDA 5050, fleets and updates, what 35 manufacturers publish on 101 models

A cleaning robot that talks to nothing but its own app covers one floor, one zone, one building. To cover a multi-storey building, it has to take the lift; to cover a whole site, it has to coexist with other robots, sometimes from other brands; to stay useful for five years, it has to receive updates; to report on its work, it has to send its data to wherever the client reads it. That is what interoperability means, and after safety it is the least documented criterion on the market. For the 101 robots from 35 manufacturers in our database, we recorded what the public documentation says on six points: lift integration, the existence of an API, adoption of the VDA 5050 standard, multi-robot fleet management, over-the-air updates and connectivity. This article gives the figures by family, names the manufacturers that publish, explains what each building block changes on a site, describes what a multi-robot operation requires, and closes with what a buyer should ask for. It will be updated every year and enriched with field feedback as it comes in. The study is consolidated in the Robotic Cleaning Observatory 2026.

The six building blocks of interoperability, and what each one changes

• Lift integration. The robot calls the car, enters it, selects the floor and exits. This requires a communication module for the lift, installed by the lift manufacturer or by an integrator, and a protocol that the robot manufacturer has implemented. Without it, one robot per floor; with it, one robot per building. It is the building block most requested by offices and hotels, and the most opaque: compatibility depends on the lift brand, its age and the module.
• The API. A documented interface that lets third-party software, a CMMS, a facility management platform or a client dashboard, read the robot's data (runs, areas, alerts) and sometimes send it commands (start a task, switch plan). Without an API, the data stays inside the manufacturer's app.
• VDA 5050. An interface standard published in 2019 by the German automotive industry and the materials-handling equipment manufacturers' association, which lets a central control system command mobile robots from different manufacturers. It has become the reference in logistics; in cleaning, it remains marginal.
• Multi-robot fleet management. A scheduler that distributes zones, timetables and docking stations across several robots, avoids conflicts and consolidates reports. At almost every manufacturer it is proprietary: it manages their robots, not anyone else's.
• Over-the-air (OTA) updates. The robot's ability to receive new functions and fixes without an on-site visit. This is what improved robot navigation and detection between 2022 and 2026, and what separates a five-year-old robot that still performs from one that has been left behind.
• Connectivity. Wi-Fi, built-in 4G or 5G, with or without an included SIM card. It conditions remote supervision, real-time reports and updates, and in a warehouse without Wi-Fi it decides everything.

Methodology

Same database and same method as our safety transparency barometer: 101 robots from 35 manufacturers, documented on 81 criteria from the public documentation of manufacturers and their distributors, checked model by model in 2025-2026. For each of the six building blocks we classified the documentation as "published" (function announced, with or without detail), "no" (function explicitly absent) and "not published" (no mention). We measure what manufacturers say, not what their robots do: an announced function may be optional, chargeable or limited to certain lift manufacturers; a function that is not published may exist. We name the manufacturers that publish, which is positive and verifiable information; we do not list "not published" models by name.

The figures

The contrast is telling: online reporting is almost universal (86%), because it serves the manufacturer as much as the client; the API, which lets the client get its data out, is published for a quarter of models; the lift, for a sixth; the open standard, for three models from a single manufacturer.

Compact multifunction robots, designed for office buildings and hotels, are the ones that most often publish lift integration; sweepers, built for single-storey warehouses, almost never do, which is consistent with how they are used.

The manufacturers that publish

Lift integration published: Gausium (8), Pudu (7), Cleanfix (1), Yijiahe (1), OrionStar (1), Ecovacs (1). API published: Gausium (12), Pudu (7), Kärcher (3), Keenon (1), Kemaro (1), Cleanfix (1), Adlatus (1). Fleet management published: Gausium (9), LionsBot (8), Pudu (7), Tennant (5), Kärcher (5), Avidbots (4), Nexaro (2), Ecovacs (2), SoftBank Robotics (1), ICE Cobotics (1), TASKI (1), Kemaro (1), Cleanfix (1), Wetrok (1), Minuteman (1), Hako (1), Fimap (1), Yijiahe (1), Tailos (1), Peppermint Robotics (1), Sveaverken (1). VDA 5050 standard: Kärcher (KIRA B 50, KIRA BR 200, KIRA BD 200). These lists are drawn from the public documentation of each model; a manufacturer that is absent may offer the function without documenting it.

Two readings. The new generation of Chinese manufacturers (Gausium, Pudu, Keenon, OrionStar, Ecovacs, Yijiahe) readily publish lift integration and a cloud platform with an API, because their home market is made of towers and shopping centres; the established European manufacturers publish less about lifts and more about safety, and, in Kärcher's case, about the VDA 5050 standard inherited from logistics. No manufacturer publishes interoperability with a competitor's robots.

What a multi-robot site requires

On a site of several tens of thousands of square metres, several robots work together: a sweeper ahead of a scrubber in the aisles, a vacuum on the office carpet while a multifunction robot scrubs the corridors, two large-format scrubbers across two halls. This cooperation, which we describe on our page about robot-to-robot cobotics, requires three things: that the robots do not get in each other's way (zones, time slots, aisle width, priority at crossings), that they share resources (docking stations, lifts, water, Wi-Fi), and that their reports can be consolidated.

Today this is done in one of two ways. With a single brand, the manufacturer's fleet scheduler does the work: it distributes zones and timetables, manages the docking stations and, where the integration exists, the lift; this is how our sites equipped with several Pudu robots run, coordinated from a single platform. With several brands, which happens when a site has a sweeper from one manufacturer and a scrubber from another, coordination is done by the organisation: separate zones and time slots in the cleaning schedule, separate docking stations, and two dashboards that the operative checks one after the other. That is not interoperability, it is juxtaposition; it works, but it costs operating time and rules out optimisation.

What we describe here are typical cases, drawn from our own practice and from the market; we will publish site-by-site figures as our clients authorise their release. The most common example: a logistics platform where an autonomous sweeper runs between 22:00 and 01:00 and a large-format scrubber between 01:00 and 05:00, with docking stations in the same plant room, and a day-shift operative who reads both reports and does the touch-ups.

What the buyer should ask for

• The API and its documentation, with the data made available (runs, areas, durations, alerts, maps) and the commands it accepts; and the ability to export the full history in an open format (CSV, JSON) at any time.
• The list of integrated lift manufacturers and modules, references of equipped sites, the cost and lead time of an integration, and who is responsible for it (manufacturer, lift company, integrator).
• The update policy: frequency, content, length of commitment (how many years of guaranteed updates), cost, and what happens at end of support.
• Fleet management: number of robots per scheduler, multi-site management, access rights per client, and compatibility with other brands (the answer will almost always be no; better to know).
• Connectivity: Wi-Fi only or built-in 4G, SIM card included, degraded operation without a network, what data is transmitted and where it is hosted.
• Reversibility: the portability of the site's maps and reports if the robot or the contractor changes, written into the contract; our specification template includes the clause.

What we do with this data

Our guide to commercial cleaning robots compares models on measurable criteria; lift integration, API and fleet management will be added model by model at the next update, in the form "published / no / not published". On our own sites we run single-brand fleets coordinated by one scheduler, and we integrate the lift where the building allows it; we hand our clients their reports in their own format, with the data export. This study may be reused freely with attribution; the aggregates are in the PDF.

The study as a PDF (methodology and aggregates)

Free to use, no registration. The six building blocks, the methodology, the aggregates by building block and by family, the manufacturers that publish and the buyer's checklist, free to reuse with attribution. Download (PDF, in French) → All our templates are gathered on the downloadable cleaning templates page.