01Platform
One platform for the chargers, the drivers, the money and the partners
zevOS is a charging management system built around a simple division of labour: the protocol layer talks to hardware and never blocks, the event layer carries the truth, and the workers turn it into sessions, invoices and settlements that reconcile.
1.6J + 2.0.1
OCPP versions
Both run side by side behind one operational surface
2.2.1
OCPI roaming
CPO and eMSP roles, seven modules
₹0
Subscription
Usage-based — the platform fee applies to sessions that earned
No app
To start charging
QR to browser, priced before the driver commits
What it does
Connect, monetise, share, operate
Four jobs. Everything on the features list is one of these done in more detail.
Connect
Every charger on your network holds a live OCPP session with the platform. Sessions, meter values, faults and firmware all move over that link — in both directions, on 1.6J and 2.0.1 alike.
- Hardware-agnostic across vendors and vintages
- Per-charger identity with rotating credentials
- Full message log retained for debugging and disputes
Monetise
Price by energy, time, hour of day or audience; take payment by UPI, card or wallet into your own merchant account; refund the unused pre-authorisation automatically; raise the GST invoice.
- Composable tariffs with time-of-day windows
- Pre-authorise, capture the true amount, refund the difference
- Tariff snapshotted onto every session — history never rewrites
Share
Almost nobody owns all the land their chargers stand on. Contracts encode the split, settlement runs produce the statements, and partners get a scoped portal instead of a monthly email thread.
- Percentage, per-kWh, fixed or minimum-guarantee splits
- Statements where every line links to its sessions
- Partner portal scoped in the data layer, not the menu
Operate
Faults decoded rather than dumped, a triage ladder that closes incidents from a desk, firmware rolled out by model cohort, and uptime measured per connector with the outage list attached.
- Remote reset ladder before any dispatch
- Diagnostics pulled before a technician leaves
- Availability you can put in a contract and substantiate
How it is built
Five layers, one rule each
The architecture exists to keep a charger from ever waiting on a database lock — and to make sure a worker restart delays processing rather than double-billing a driver.
- 01
OCPP gateway
Speaks the protocolHolds a long-lived WebSocket session with every charger. Validates and normalises each frame, responds immediately, and emits a domain event. It writes nothing to the database and applies no billing or authorisation logic — because a gateway that blocks is a charger that disconnects.
- 02
Event stream
Carries the truthNormalised events — session started, meter value recorded, charger faulted, command acknowledged — move on Redis streams with consumer groups. Unacknowledged messages are reclaimed on restart, so a worker crash delays processing rather than losing it.
- 03
Workers
Does the thinkingIdempotent consumers apply the events: creating and closing sessions, computing cost against the snapshotted tariff, updating availability, triggering payments and refunds, and raising alerts. Every handler is keyed so reprocessing a duplicate is a no-op.
- 04
API & console
Where people workA FastAPI service with tenant scoping applied in the data-access layer rather than trusted to individual queries, and a Next.js console that renders the same data an operator would get from the API — because it is the same API.
- 05
Driver surfaces
Where money startsThe QR charging flow, the driver apps and the station map. Built to work on a bad connection for someone who has never used them before, under your brand rather than ours.
Feature map
The whole surface, grouped
Each of these has its own page with the specifications, the limits and the roadmap items stated separately from what ships today.
Operations
Keep every charger online, diagnosed and under control from one screen.
Commerce
Price the energy, take the money, split the revenue, raise the invoice.
Drivers & partners
The people who charge, and the people whose sites you charge on.
Platform
The parts underneath: identity, isolation, protocols and APIs.
zevOS Copilot
Ask your network a question and get the records behind the answer.
White-label
Your brand on the driver app, the receipts and the partner portal.
Supported chargers
What a charger must implement, and what to specify when buying.
Developer hub
The API the console itself runs on, plus webhooks and patterns.
See the platform against your own network
Bring your charger models, your tariff structure and your partner agreements. We will show you how each of them is handled.