What is OCPP? (Open Charge Point Protocol)

OCPP — the Open Charge Point Protocol — is the open standard that defines how an EV charging station talks to the central system that manages it. If you build or integrate a CSMS/CPMS, the OCPP protocol is the wire contract your software must speak: identity, authorization, session start/stop, metering, and remote control.

The Open Charge Alliance maintains the specifications (official download). Vendors implement them so chargers from one manufacturer can work with backends from another. Chargeflux is not the standards body; we ship a hosted OCPP charge point simulator so you can exercise that contract against your CSMS without a hardware lab.

OCPP protocol in one sentence

The OCPP protocol is a request/response messaging model over a long-lived connection (almost always WebSocket + JSON today) between a Charge Point (station / EVSE side) and a CSMS (Charging Station Management System — the backend).

The two roles: Charge Point and CSMS

Every OCPP conversation has two sides with fixed jobs:

• Charge Point (also called a charging station or EVSE in product language) — the station with one or more connectors. It boots, heartbeats, reports status, starts local or remote sessions, and publishes meter values. Chargeflux simulates this side with a browser UI and a cloud-hosted runtime.
• CSMS (Charging Station Management System / CPMS) — authorizes drivers or tokens, accepts or rejects boot, starts and stops sessions remotely, stores meter data, and monitors availability. You connect the simulator to your CSMS endpoint.

People sometimes say “OCPP server” for the CSMS and “OCPP client” for the station. That maps to who opens the WebSocket in common 1.6J deployments: the charge point initiates the connection to the central system URL.

How the OCPP protocol communicates

In OCPP 1.6J, the station opens a WebSocket to the CSMS and both sides exchange JSON frames. The J means JSON; there is also a SOAP variant of 1.6 that most new software stacks no longer target. Chargeflux focuses on JSON over WebSocket.

Framing uses three message types:

CALL       [2, uniqueId, action, payload]
CALLRESULT [3, uniqueId, payload]
CALLERROR  [4, uniqueId, errorCode, errorDescription, errorDetails]

Each CALL carries a unique ID. The matching CALLRESULT or CALLERROR repeats that ID so every request pairs with a response. A practical OCPP 1.6 simulator shows that correlation in a message console — essential when a CSMS “accepts” boot but never answers Authorize.

Connection failures (TLS, subprotocol, path, idle timeouts) are still the first blocker for many teams. See WebSocket troubleshooting and connect your CSMS.

OCPP 1.6 vs OCPP 2.0.1 (decision guide)

“What is OCPP?” usually leads straight to version choice. Use this table when product and eng argue about dual-stack scope:

If your CSMS claims both versions, treat them as two integration surfaces — not one checkbox. Dual-stack bugs show up when teams only ever boot a 1.6 station in demos. Full comparison including 2.1: OCPP 1.6 vs 2.0.1 vs 2.1.

Station identity and connectors

A Charge Point connects using a station identity (for example CF-DEMO-A7K2). Each physical outlet is a numeric connector ID (1, 2, …). Connector ID 0 is reserved for Charge Point-level status and commands, not a normal charging outlet. Wrong identity or connector numbering is a common reason a CSMS “never sees” the session you think you started.

Core OCPP 1.6 message vocabulary

You do not need every profile on day one. A typical integration loop uses a small set of Core messages:

• BootNotification — station introduces itself; CSMS accepts or rejects operation and often returns heartbeat interval.
• Heartbeat — keeps the link alive and helps clock sync.
• StatusNotification — connector state (Available, Preparing, Charging, Faulted, …).
• Authorize — may this idTag charge?
• StartTransaction / StopTransaction — session boundaries for billing and history.
• MeterValues — energy and electrical samples during a transaction.

The CSMS can send commands such as RemoteStartTransaction, RemoteStopTransaction, ChangeAvailability, and Reset. Copy-paste JSON and trigger timing live on OCPP 1.6J sample messages. Drive both directions with the simulator and inspect frames in the console.

A simple session loop (what “working OCPP” feels like)

1. Station opens WebSocket → CSMS
2. BootNotification → Accepted (+ heartbeat interval)
3. StatusNotification (Available)
4. Authorize (idTag) → Accepted
   — or CSMS RemoteStartTransaction
5. StartTransaction → transactionId
6. MeterValues while Charging
7. StopTransaction
8. Status back to Available

If any step hangs without a CALLRESULT, fix that before debating tariff logic. For a hardware-free checklist aimed at CPO software teams, see test CSMS without hardware.

Why software teams care about the OCPP protocol

• Interoperability — multi-vendor chargers and backends only work if both ends implement the same version and message expectations.
• Operations — remote start/stop, availability, and reconnect behaviour are product features, not nice-to-haves.
• Billing truth — MeterValues shape and cadence break session UIs and settlement when wrong.
• Speed of integration — waiting on a lab EVSE stalls CSMS releases; a OCPP charge point simulator (virtual charge point) shortens the loop.

What OCPP is not

• Not a driver-facing app protocol (that sits above or beside your CSMS product).
• Not OCPI / roaming — that is CPO ↔ eMSP. See OCPI vs OCPP.
• Not automatic certification — passing messages in a simulator is not the same as an official Open Charge Alliance conformance process.
• Not “one API forever” — 1.6J and 2.0.1 differ enough that dual-stack needs explicit tests.

How to learn OCPP by testing (not only reading)

Spec PDFs teach names. A running station teaches timing, identity mistakes, and which fields your CSMS actually validates. Practical path:

1. Skim this page for roles and the Core vocabulary.
2. Getting started — first BootNotification under a minute.
3. Walk Core flows on the OCPP 1.6 simulator.
4. If you claim 2.0.1 support, repeat on the OCPP 2.0.1 simulator.
5. Automate with the API once the happy path is stable.

Launch the OCPP simulator · 1.6J samples · 2.0.1 samples · Pricing

FAQ

What does OCPP stand for?

Open Charge Point Protocol — the open standard for communication between EV charging stations and a central management system (CSMS).

What is the OCPP protocol used for?

It standardizes how stations register, authorize sessions, report status and meter data, and accept remote commands from a backend. Without it, every charger–backend pair would need a private integration.

Is OCPP the same as Open Charge Point Protocol?

Yes. OCPP is the acronym; Open Charge Point Protocol is the full name.

Which OCPP version should a new CSMS support first?

Most teams still need solid OCPP 1.6J for fleet reality, then add OCPP 2.0.1 when customers or programmes require it. Support both only if you will test both — not as a slide-deck claim.

Is OCPP a REST API?

No. Production OCPP is typically WebSocket frames with CALL / CALLRESULT / CALLERROR, not a generic REST resource model. Some products expose REST around their CSMS; that is a product API, not OCPP itself.

How do I test the OCPP protocol without hardware?

Use a virtual charge point / OCPP simulator that opens a real WebSocket to your CSMS and drives Boot, Authorize, transactions, and MeterValues. Chargeflux hosts that runtime so QA and eng share the same station identity and logs — see test CSMS without hardware.

Does Chargeflux implement every OCPP feature?

Chargeflux supports OCPP 1.6J and 2.0.1 for CSMS testing workflows documented in the simulator guides. It is a development and testing tool, not an official certification lab. OCPP 2.1 is on the roadmap without a promised date.

Last reviewed August 2026 · Chargeflux.io