What Is OCPP? The Open Charge Point Protocol Explained

OCPP — the Open Charge Point Protocol — is the language that EV charging stations use to talk to the back-end systems that operate them. If you’ve ever wondered how a charger knows whether your card is allowed to charge, how the operator knows when a session started, or how new pricing gets pushed to a charger overnight — that’s OCPP.

It’s one of the most important standards in EV charging, and one of the least understood outside the small group of people who work on it. This article is a thorough introduction.

Why OCPP exists

In the early 2010s, every EV charging station was a tiny island. The manufacturer of the hardware (the OEM) usually also operated the back-end system. If you bought a charger from Brand A, it talked to Brand A’s cloud, and only Brand A’s cloud. Mixing chargers from different brands in a single network was technically possible but operationally painful — you’d run two parallel back-ends and reconcile data manually.

Operators (CPOs — Charge Point Operators) hated this. They wanted to choose the best hardware for each location and run all of it through one operations platform. Hardware vendors hated it too — being locked into their own back-end limited their addressable market.

In 2009 the ELaadNL foundation in the Netherlands led a coalition of utilities, manufacturers, and operators to define a vendor-neutral protocol. OCPP 1.2 came out in 2010. OCPP 1.5 followed. Then OCPP 1.6 in 2015 became the workhorse version that still runs millions of chargers today. OCPP 2.0 came in 2018 (and was quickly superseded by 2.0.1 with important corrections). OCPP 2.1 came in 2024-2025 with more refinements and ISO 15118 integration improvements.

The protocol is published and maintained by the Open Charge Alliance (OCA), a non-profit industry consortium with members across the entire EV charging value chain.

The two sides of an OCPP connection

OCPP is between a charge point (also called a charging station, EVSE, or charger) and a CSMS (Charging Station Management System, also called a back-end, back-office, or central system).

• The charge point is the physical hardware that delivers electricity to the vehicle. It has firmware, a WebSocket client, a connector or two, a payment terminal sometimes, an RFID reader sometimes.
• The CSMS is the cloud system that monitors the charger, authorizes sessions, configures pricing and behavior, collects metering data, and serves as the integration point to higher-layer systems (OCPI roaming, billing, customer app, etc.).

The CSMS is operated by the CPO. One CSMS manages anywhere from a handful to hundreds of thousands of charge points.

flowchart LR
    V[Vehicle] -->|ISO 15118<br/>or IEC 61851| CP[Charge point]
    CP <-->|OCPP<br/>WebSocket| CSMS[CSMS<br/>cloud backend]
    CSMS <-->|OCPI| RP[Roaming partners<br/>eMSPs, hubs]
    CSMS --> BD[Billing, app,<br/>ops dashboards]
    style CP fill:#dbeafe,stroke:#2563eb
    style CSMS fill:#dcfce7,stroke:#16a34a

OCPP is the middle link. Vehicle-to-charger is ISO 15118 (or simpler signaling). Operator-to-operator is OCPI. OCPP is operator-to-its-own-hardware.

What OCPP actually does

The protocol has a long list of message types but they cluster into a few job families.

Session lifecycle.

• Authorize a user’s identifier (RFID card, app token, ISO 15118 contract).
• Start a transaction (in 1.6) or send a TransactionEvent (in 2.0.1).
• Send periodic meter readings during the session.
• Stop the transaction and report the total energy delivered.

Operational status.

• Heartbeat — the charger pings the CSMS regularly to confirm it’s alive.
• StatusNotification — the charger reports state changes (Available, Preparing, Charging, Faulted, etc.) for each connector.
• BootNotification — identification when the charger comes online.

Configuration and control.

• ChangeConfiguration / SetVariables — the CSMS pushes new settings to the charger.
• TriggerMessage — the CSMS asks the charger to send something specific.
• Reset — the CSMS reboots the charger.
• RemoteStartTransaction / RequestStartTransaction — the CSMS initiates a session remotely (used when a user starts via the app).

Firmware and diagnostics.

• UpdateFirmware / SignedUpdateFirmware — push new firmware to the charger.
• GetLog / DiagnosticsStatusNotification — pull diagnostic logs when something is wrong.

Smart charging.

• SetChargingProfile — define when and how much power the charger can deliver.
• ClearChargingProfile / GetCompositeSchedule — manage and inspect those profiles.

Reservation.

• ReserveNow / CancelReservation — block a connector for a specific user.

In OCPP 2.0.1 and later there’s also a richer security stack (signed messages, certificate-based mutual auth, key rotation), a “device model” for representing the charger’s internal structure (controllers, EVSEs, connectors, sensors), and explicit support for ISO 15118 Plug & Charge.

How the conversation actually flows

A typical session, simplified:

1. Charge point boots. Opens a WebSocket connection to the CSMS URL it has configured. Sends BootNotification with its identity and capabilities.
2. CSMS responds with Accepted plus the heartbeat interval and the registration status.
3. Charge point starts heartbeating. Every 5 minutes (or whatever interval) it sends Heartbeat and gets a response with the current server time (used for clock sync).
4. A user plugs in a vehicle and presents an RFID card. Charge point sends Authorize with the card’s ID.
5. CSMS checks — is this card on our local whitelist? If not, query the eMSP via OCPI. Respond with Accepted or Invalid.
6. If accepted, the charge point sends StartTransaction (1.6) or TransactionEvent (Started) (2.0.1). This includes the start meter reading and the connector ID.
7. Charging proceeds. Periodically the charge point sends MeterValues (or TransactionEvent (Updated) in 2.0.1) with current power, energy, and other sampled metrics.
8. Vehicle reaches its target SOC or the user unplugs. Charge point sends StopTransaction (1.6) or TransactionEvent (Ended) (2.0.1) with the final meter reading.
9. CSMS processes the completed transaction — bills the user, generates a CDR for roaming partners (via OCPI), updates dashboards.
10. Throughout, StatusNotification messages keep the CSMS aware of connector state (Available → Preparing → Charging → Finishing → Available).

Each of these messages has a request and a response. OCPP uses a request/response pattern with unique message IDs to correlate them.

The transport: WebSocket and JSON

OCPP 1.5 used SOAP over HTTP. That was a mess — verbose, hard to debug, polling-based, and didn’t deal well with chargers behind NAT or firewalls.

OCPP 1.6 switched to WebSocket (with a fallback SOAP option that essentially no one uses). The charger opens a persistent WebSocket connection to the CSMS and keeps it open. Both sides can send messages whenever they want. Messages are JSON.

A typical OCPP message on the wire:

[2,"abc123","BootNotification",{"chargePointVendor":"ExampleCo","chargePointModel":"X1"}]

The format is:

• 2 — message type (2 = Call/request, 3 = CallResult/response, 4 = CallError/error)
• "abc123" — unique message ID for correlation
• "BootNotification" — the action name
• {...} — the payload

The response would be:

[3,"abc123",{"currentTime":"2026-06-26T08:00:00Z","interval":300,"status":"Accepted"}]

It’s a simple, debuggable protocol once you get over the array-format weirdness. You can open the network tab in Chrome DevTools on a CSMS dashboard and watch messages flow in real time.

The version differences in one paragraph each

OCPP 1.6 — the workhorse. JSON over WebSocket. Roughly 30 message types. Works. Lacks a security model (the security extensions came as a separate add-on in 2018), has a confusing transaction lifecycle (StartTransaction, StopTransaction, MeterValues), and the data model is essentially free-form. Most deployed chargers today run 1.6.

OCPP 2.0.1 — the modernization. Restructured transactions (single TransactionEvent message replacing StartTransaction/StopTransaction). Introduced the device model for richer charger representation. Native security with mutual TLS and signed messages. Better support for multiple connectors per EVSE. Cleaner smart-charging primitives. Explicit ISO 15118 Plug & Charge integration. About 40+ message types but better organized.

OCPP 2.1 — the iteration. Released 2024-2025. Smaller delta than 1.6 → 2.0.1 was. Refinements to the device model, bidirectional power flow support (V2G), better tariff handling on the charger side, improved certificate management for Plug & Charge. Most CPOs are still planning their 2.0.1 → 2.1 migration.

A dedicated comparison article covers the differences in much more depth.

Where OCPP doesn’t reach

A few clarifications about what OCPP is NOT responsible for.

OCPP doesn’t decide whether to authorize a user. It carries the authorization request, but the CSMS makes the decision (sometimes after asking an eMSP via OCPI).

OCPP doesn’t define the actual electricity delivery. That’s between the charger’s internal control and the vehicle, via lower-level signaling (IEC 61851 PWM, or ISO 15118 for the richer cases).

OCPP doesn’t handle payment processing. It can carry meter values that feed into billing, but payment APIs (Stripe, Adyen, etc.) are outside OCPP.

OCPP doesn’t define the charger’s user interface. Whether the charger has an LCD, a buzzer, a contactless reader, a screen showing tariffs — all up to the OEM.

OCPP doesn’t do roaming. When a user from eMSP A charges at a CPO B station, OCPP doesn’t know about eMSP A. The CSMS handles the eMSP relationship via OCPI; the charger only sees the CSMS.

Why OCPP matters for the industry

A short list of why OCPP is foundational:

• It made vendor-neutral charging infrastructure possible. Without it, every brand would be a silo.
• It enabled the rise of independent CPOs that don’t manufacture their own hardware.
• It enabled the CSMS market as a category — companies like ChargePoint, EV Connect, and Driivz (in North America) and AMPECO, has•to•be, and Etrel-Landis+Gyr (in Europe) build platforms that work across hardware brands precisely because OCPP exists.
• It’s the contract between the hardware OEM and the operator that enables the entire downstream OCPI roaming ecosystem.

If OCPP didn’t exist, the EV charging industry would look more like the early cellular industry where every carrier had its own handsets. Instead, it looks more like the modern internet where any device that speaks the standards can talk to any service that speaks them.

What to learn next

If you’re new to OCPP, the natural next reads are:

• A deep comparison of OCPP 1.6 vs 2.0.1 vs 2.1 ^{(coming soon)} so you understand what each version brings.
• The BootNotification message deep-dive ^{(coming soon)} for a feel of what a single OCPP message actually contains.
• The OCPP vs OCPI vs ISO 15118 explainer to fit OCPP into the bigger protocol picture.

If you’re choosing a CSMS, you want one that speaks the OCPP version you’ll standardize on (probably 2.0.1) and has a clean upgrade path to 2.1. If you’re choosing chargers, look for firmware that supports both 1.6 and 2.0.1 so you have flexibility.

OCPP is one of those technologies that’s invisible when it works. Hundreds of millions of EV charging sessions globally each year flow through OCPP-spoken connections. The protocol’s success is part of why the EV charging industry has been able to scale at all.