OCPP proxy: what it is and when you need one

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 a single 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, and an OCPP proxy removes it. The Plugchoice OCPP proxy is free. The charger connects once to Plugchoice, and Plugchoice relays its OCPP traffic to one or more backends (CSMS) at the same time. Adding or removing a backend is a toggle, so the charger is never reconfigured, and messages are held while a connected backend is down.

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.

Software in that position also goes by other names, gateway and broker among them. They do not all mean the same thing; OCPP proxy vs gateway vs broker compares them.

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

The free Plugchoice OCPP proxy works on this model. Chargers connect to wss://ocpp.plugchoice.com, Plugchoice stays the control layer (portal, app, diagnostics and configuration stay available whichever backends you connect), and the proxy relays OCPP traffic to the back offices you add.

A few specifics of the implementation:

• Any OCPP 1.6J backend. The back offices in the integrations directory are ready to pick from a list. Any other back office that speaks OCPP 1.6J connects with its websocket URL.
• A role per back office. Billing hands a back office card authorisation, sessions and transactions. Data and control lets it read everything and send commands, but never start or stop a session.
• Messages held while a backend is offline. When a connected back office goes down, the proxy holds its OCPP messages and replays them when it reconnects, so sessions are not lost in the gap.
• Every message logged. Each OCPP message to and from the charger is stored, filterable and exportable.
• A toggle to connect or disconnect. Back offices are switched on and off in the portal or the app. Leaving a platform is a toggle, not a project.

The proxy speaks OCPP 1.6J, depending on the charger's model, firmware and configuration. The OCPP 1.6J guide lists the messages it relays.

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.

Can one charger connect to two backends at once

Yes, through an OCPP proxy. With Plugchoice the charger connects once to Plugchoice, and Plugchoice relays the same OCPP traffic to several backends at the same time, for example a billing platform and an energy platform, each in its own role. The second backend is added with a toggle in the portal; the charger keeps its single connection and is not reconfigured.

Sources

• Open Charge Alliance, the organisation behind OCPP
• OCPP 1.6 specification overview
• Plugchoice OCPP proxy