One API. Every Vehicle.
Connect OKAI, Omni, Segway, Queclink, and more through a single REST API. Lock, unlock, track, and manage your entire fleet — regardless of hardware.
Built from Live Operations
Not a concept deck. A normalized control plane already in production.
Switchboard is the same IoT infrastructure that powers Levy Fleets — a fleet management platform serving 30,000+ vehicles across multiple cities and hardware families. Now available as a standalone API for any operator.
Switchboard is the IoT backbone behind Levy Fleets, managing 30,000+ vehicles across multiple cities and vehicle types.
TCP, MQTT, REST, and vendor-specific command lifecycles behind one API.
Designed around confirmed state changes instead of fire-and-forget dispatch.
Heartbeats, reconnects, and offline transitions surfaced as product signals.
Your fleet software should not care which board is inside the vehicle.
Operators usually end up in one of two bad places: rebuilding every vendor protocol in-house or layering their business on top of a generic middleware abstraction that was never designed for micromobility operations.
Build Every Protocol Yourself
Maximum control, maximum engineering drag. It works until procurement changes hardware and your roadmap turns into protocol maintenance.
Use Generic Middleware
Faster to start, but often too far from actual operations. You get an abstraction layer, not necessarily a control plane built around lock, unlock, and state confirmation.
Switchboard packages the missing middle layer.
Normalize device state across hardware families, confirm commands against live telemetry, and expose the whole thing as a product-ready API with webhooks, fleet-level access, and operational visibility from day one.
How It Works
From unboxing to API calls in under an hour
Register Devices
Add your IMEIs and hardware type via the API or dashboard. Switchboard provisions a device record. When the device connects for the first time — via TCP handshake (OKAI, Queclink) or MQTT CONNECT (Omni, ZIMO) — it auto-associates by IMEI. No manual pairing step.
Point to Switchboard
For TCP devices (OKAI, Queclink): update the server IP and port via the manufacturer's BLE config app — one Bluetooth connection per device, about 30 seconds each. For MQTT devices (Omni, ZIMO): update the broker address. That's the only change on the hardware side.
Devices Connect
TCP devices establish persistent socket connections. MQTT devices authenticate with ICCID as the client ID and subscribe to their command topic. Switchboard handles heartbeat SACK responses (OKAI), MQTT keep-alive, LWT disconnect detection, and automatic reconnection across all protocols.
Use the API
Lock, unlock, locate, throttle, speed-limit — all through REST calls. Commands return confirmed/timeout/failed status based on actual device acknowledgment, not just message delivery. Telemetry is normalized into a single schema regardless of hardware. Webhooks stream events in real time.
Built for Production Fleets
Every feature battle-tested across hundreds of devices in real rider traffic
Unified REST API
One endpoint schema regardless of hardware vendor. POST /devices/{imei}/lock dispatches an AT+GTRTO command over TCP for OKAI, a JSON 'stop' message on the device's MQTT subscribe topic for Omni, or a binary control frame for Queclink — but your integration code is identical. Responses follow the same normalized schema: device state, command status, and the latest telemetry snapshot.
Command Confirmation
We don't return 'sent' and hope. After dispatching a command, Switchboard polls for a state-change acknowledgment from the device — an OKAI GTULS response confirming ecuLockEngaged, an Omni MT2 telemetry report with scooterLocked: true, or a Queclink ACK frame. Only when the device confirms the physical state change do we return status: 'confirmed'. If the device doesn't respond within the timeout window (configurable, default 16 seconds), you get status: 'timeout' with the last known state so your app can decide what to do next.
Real-Time Telemetry
Normalized telemetry across all hardware: lat/lon, GPS timestamp, speed (km/h), vehicle battery (%), IoT module battery (separate from vehicle), lock state (boolean), ignition (boolean), odometer (km), heading (degrees), altitude (m), signal strength (RSSI in dBm), charging state, and online status. OKAI reports ignition via GTSPD subcodes (0x18 throttle on, 0x19 throttle off). Omni reports it as a boolean in the MT2 JSON payload. Smart Guard reports voltage and fuel level. You get the same normalized fields regardless of vehicle type or hardware.
Heartbeat & Connection Monitoring
OKAI devices send GTHBD heartbeat packets over TCP and expect the server to reply with a SACK (server acknowledgment) within the heartbeat interval — miss it and the device disconnects, queuing commands that silently fail. Switchboard handles SACK responses automatically. For MQTT devices (Omni, ZIMO), we monitor MQTT keep-alive and last-will-and-testament (LWT) messages. Every device has a tracked lastSeen timestamp; online/offline transitions fire as webhook events.
Geofencing Engine
Define zones as GeoJSON polygons with properties: max speed, auto-lock on exit, no-ride designation. As telemetry streams in, each GPS fix is evaluated via point-in-polygon tests. Zone enter/exit events fire with zone ID, event type, and triggering coordinates. For speed enforcement, Switchboard can send throttle-limit commands to hardware that supports it — OKAI via AT+GTSPD, Omni via the 0x11 speed mode UART command. Zone events are also written to a queryable event log for post-hoc ride path analysis.
Signed Webhooks
Event types: device.online/offline (connection state), device.telemetry (periodic GPS/battery at configurable intervals), command.confirmed/timeout/failed (full command lifecycle), zone.enter/exit (geofence transitions), device.low_battery (configurable threshold), device.tamper (hardware-dependent), trip.start/end (if using trip lifecycle). Each payload includes device ID, hardware type, ISO 8601 timestamp, event type, and the full current telemetry snapshot. Delivered with HMAC signatures, retried with exponential backoff on 4xx/5xx.
Multi-Tenant Isolation
Each fleet gets its own API key and device pool. API keys can only see and command devices assigned to their tenant — no cross-tenant visibility at the API level. Webhooks are delivered per-tenant with tenant-specific HMAC signing secrets. All tenants share infrastructure but device records, command history, and event logs are isolated by tenant ID. Enterprise plans can deploy a fully isolated proxy instance per tenant for additional separation.
OTA Firmware Updates
OKAI devices support firmware upgrades via the AT+GTUPD command set, staging binaries over the TCP connection. Omni devices support both IoT firmware and ECU (motor controller) firmware updates via MQTT commands with chunked binary delivery. Switchboard orchestrates the process: upload a firmware binary, select targets (individual IMEI, by model, or by fleet), and we handle delivery, progress tracking, and rollback if the device doesn't report healthy post-update. Staged rollouts push to 5% first, verify, then expand.
How the Architecture Works
Switchboard sits between vendor-specific device behavior and your application stack, so you only build once even when your hardware mix changes.
Device Protocols In
Vendor-specific transports, topics, and command formats stay isolated in adapters.
Switchboard Control Plane
The place where raw protocol behavior becomes a consistent product interface.
Apps and Workflows Out
Your customer-facing and internal systems consume one API, not five vendor specs.
Normalized state model
One device shape for battery, location, lock state, ignition, and online status.
Command lifecycle
Dispatch, pending, confirmed, failed, and timeout states surfaced as application-level events.
Webhook fan-out
Stream status changes, trip events, offline alerts, and geofence transitions into your stack.
Protocol onboarding
New hardware gets mapped into the same API instead of forcing an app rewrite.
Supported Hardware
One integration to rule them all. We add new protocols monthly.
OKAI
LiveTCP / AT Commands (EF80xx firmware)
ES200, ES400, EB100 e-bikes
Omni
LiveMQTT v3.1.1 / JSON (Lannmarker V2.9)
ACTON, Lannmarker IoT boards
Queclink
LiveTCP / Proprietary Binary Frames
GL300, GL500, GV series GPS trackers
ZIMO
LiveMQTT / JSON (proprietary topic schema)
Multi-vehicle IoT modules
Smart Guard
LiveREST / Telematics API (polling + webhooks)
Connected vehicle security modules
Segway-Ninebot
Coming SoonComing soon
Max, KickScooter series
Example API Calls
Representative requests and normalized responses from the Switchboard API
Request
curl -X POST https://api.switchlabs.dev/v1/devices/860012345678/lock \ -H "Authorization: Bearer sk_live_xxx" \ -H "Content-Type: application/json"
Response
{
"deviceId": "860012345678",
"hardware": "okai",
"command": "lock",
"status": "confirmed",
"latencyMs": 2847,
"protocol": {
"transport": "tcp",
"commandSent": "AT+GTRTO=lock",
"ackReceived": "GTULS",
"stateCode": "0x41"
},
"telemetry": {
"lat": 37.9876,
"lon": -87.5432,
"battery": 72,
"locked": true,
"ignition": false,
"speed": 0,
"gpsTimestamp": "2026-03-11T22:14:03Z"
}
}Security and Reliability
Enterprise buyers need more than protocol support. They need confidence that access, events, deployment, and operations can hold up in production.
Access Control
Per-fleet API keys, separated device pools, and role-aware operational access.
Event Integrity
Signed webhook delivery and a normalized event stream that is easier to verify downstream.
Deployment Options
Shared cloud, private cloud, or on-prem deployments depending on fleet size and requirements.
Operational Visibility
Connection health, command status, and offline transitions surfaced as reviewable signals.
Security Review Ready
If a fleet, city partner, or insurance team needs to understand how traffic flows and where responsibilities sit, we can walk them through the architecture instead of hand-waving over it.
Reviewable command history, normalized device state, and clearer ownership between the app layer and hardware layer.
Shared-hosted for speed, private deployment for tighter controls, or on-prem when procurement requires it.
How Switchboard Stacks Up
Purpose-built for micromobility, not a generic integration layer
| Feature | Switchboard | Legacy Middleware | DIY | Generic IoT Platform |
|---|---|---|---|---|
| Built for micromobility and light EV fleets | ||||
| Confirmed command execution (not just 'sent') | ||||
| Command lifecycle (confirmed / timeout / failed) | ||||
| Heartbeat SACK handling (TCP protocols) | ||||
| MQTT keep-alive + LWT disconnect detection | ||||
| Normalized telemetry model across hardware | ||||
| Per-zone speed limiting via device commands | ||||
| Signed webhook delivery with retry + backoff | ||||
| Multi-tenant fleet isolation | ||||
| Staged OTA firmware rollouts | ||||
| Setup time to first API call | Hours | Weeks | Months | Days |
| Protocol onboarding from manufacturer spec | 1-2 weeks | Months | ||
| Zero-downtime migration from existing middleware | ||||
| On-prem / private cloud deployment option |
This reflects the typical tradeoffs operators run into when choosing between a purpose-built micromobility API, legacy middleware, a generic IoT platform, or a fully in-house build.
Simple, Transparent Pricing
Indicative monthly pricing for live fleets. Deployment model and protocol mix can adjust final scope.
Starter
For pilots and small fleets
Up to 100 devices ($0.49/device)
Growth
For growing operations
Up to 500 devices ($0.30/device)
Fleet
For multi-city operators
Up to 2,000 devices ($0.20/device)
Enterprise
Need more than 2,000 devices, on-prem deployment, or a custom protocol? Tell us about your fleet.
Request Access
Tell us about your fleet.
Share your hardware mix, deployment timeline, and rough fleet size. We will reply with fit, migration notes, and the fastest path to a live pilot.
Fast fit check
We can tell you quickly whether your current hardware mix fits the normalized API.
Migration plan
Share your vendor stack and we will outline the cleanest path from existing middleware or direct integrations.
Protocol review
If your hardware is new, we can scope protocol onboarding from the spec before you commit.
Frequently Asked Questions
Everything you need to know about Switchboard