Almost every modern EV charger speaks OCPP, the open protocol that connects chargers to a management platform. In theory that means you can point a charger at any backoffice you like. In practice, most chargers hold exactly one OCPP connection: one WebSocket URL, configured in the charger, pointing at one platform. Everything you do with that charger, billing, diagnostics, smart charging, reporting, runs through whichever platform sits at the end of that URL.
That single connection is where lock-in lives. An OCPP proxy is the piece of infrastructure that removes it.
Why chargers end up locked to one backend
The charger's OCPP endpoint is not something you change casually. It usually means reaching the charger's configuration through an installer app, a service menu or a site visit, and getting it wrong can leave a charger offline. So once a charger is commissioned against a platform, it tends to stay there, even when the platform stops fitting.
And platforms do stop fitting. A billing provider changes pricing. An operator contract ends. A backend shuts down or changes direction, and suddenly the question is not "which platform is best" but "how do we re-commission hundreds of chargers". For installers and charge point operators, that reconfiguration project is real work with real downtime.
There is a second, quieter problem: one connection means one platform gets everything. If your billing platform holds the OCPP connection, it also controls your diagnostics, your configuration access and your data. Want a separate analytics tool, or an energy management system reading the same sessions? With a single direct connection, you cannot have both.
What an OCPP proxy does
An OCPP proxy sits between the charger and the platforms. The charger connects to the proxy once, and the proxy forwards OCPP messages onward to one or more backends. To the charger, the proxy looks like its backend. To each connected platform, the proxy looks like the charger.
That one change in topology has two consequences.
First, the charger's configuration becomes permanent. It points at the proxy and never needs to change again. Which platforms receive its traffic is decided in the proxy, in software, not in the charger's settings.
Second, "one charger, one platform" stops being a rule. The proxy can forward messages to several platforms at once, each with its own role: one handles billing, another receives session data for analytics, and the management layer stays available underneath.
Switching backends without downtime
This is the scenario the proxy exists for. Say your chargers are commissioned against billing platform A, and you want to move to platform B.
Without a proxy, that is a migration: reconfigure every charger to the new WebSocket URL, hope firmware and settings cooperate, and accept a window where sessions, cards and reporting are in limbo.
With a proxy, it is a routing change. You add platform B as an operator on the proxy, verify it sees the chargers and processes sessions correctly, then disable the route to platform A. The chargers never notice. There is no site visit, no re-commissioning, and no period where the fleet is unmanaged, because the layer the chargers actually connect to never went away.
The same mechanic works in reverse: you can trial a new platform on a handful of chargers, in parallel with your current setup, before committing your whole fleet to it.
When a proxy makes sense
A proxy is not for everyone. A homeowner with one charger and one app is usually fine with a direct connection. The proxy starts paying for itself when any of these are true:
- You operate chargers for others. Installers and CPOs who commission fleets want to keep hardware access independent from whichever billing operator a customer picks today.
- Different sites need different platforms. A proxy lets you mix billing or automation platforms across a fleet while keeping one management layer for all of it.
- You need more than one system on the same charger. Billing on one platform, monitoring or an energy management system on another, both fed by the same OCPP stream.
- You want a way out before you need one. If a backend raises prices, degrades or disappears, rerouting beats re-commissioning. Backend churn is not hypothetical in this market; charger owners have seen platforms restructure and shut down with their chargers still on the wall.
How the Plugchoice OCPP Proxy works
Plugchoice runs a free OCPP Proxy built exactly on this model. Chargers connect to Plugchoice, Plugchoice stays the control layer (portal, apps, diagnostics and configuration remain available at all times), and the proxy routes OCPP traffic onward to whatever platforms you connect.
A few specifics of the implementation:
- Any WebSocket endpoint. You can point the proxy at any OCPP operator, whether or not it is in the integrations directory. If it speaks OCPP, it can be connected.
- Role-based access. Each connected operator gets a role. A billing operator handles card authorization, sessions and transactions. A data operator receives charging data read-only, for analytics or compliance, without control over sessions.
- Offline buffering. When a connected operator goes down, the proxy buffers and caches OCPP messages until it reconnects, so sessions are not lost in the gap.
- Filtering and priority rules. You control which messages are forwarded to which operator and at what rate, and built-in priority rules prevent connected systems from overruling each other.
- Connect and disconnect in minutes. Operators are enabled and disabled per location in the portal. Leaving a platform is a toggle, not a project.
The result is that the charger layer stays yours. Platforms above it can come, go and coexist, and none of them can take your hardware access with them.
If you want to see whether this fits your setup, start at the OCPP Proxy page or connect a charger and try it on one site first.