EV charger reservations sound simple. Save a spot for me. Underneath that sentence sits real protocol complexity. The OCPP reservation flow involves the back-end pushing a reservation to a specific charger, the charger enforcing the reservation against unauthorized users, and the lifecycle of reservation creation, expiration, and fulfillment. If you are new to the protocol itself, what OCPP is covers the CSMS-to-charger relationship this article builds on.
This article walks through how OCPP reservations actually work, the common patterns, and where the operational complications hide.
The basic flow
A typical reservation lifecycle:
- User requests a reservation via their app for a specific charger at a specific time.
- eMSP back-end sends an OCPI Command (ReserveNow) to the CPO. The CPO and eMSP roles matter here, because the reservation crosses an organizational boundary before it ever reaches the charger.
- CSMS receives the Command and sends OCPP ReserveNow to the specific charger.
- Charger checks availability. Is the connector currently Available, or already in use?
- Charger responds with Accepted, Faulted, Occupied, Rejected, or Unavailable.
- If Accepted, the reservation is active. The charger refuses sessions from other users until expiration or fulfillment.
- User arrives, plugs in. Their authorization matches the reservation. Charging starts on the same authorization path a remote start uses, gated by the reservation.
- Or reservation expires. Charger releases the reservation; connector becomes available.
The connector moves through a small set of states across that lifecycle:
stateDiagram-v2
[*] --> Available
Available --> Reserved: ReserveNow<br/>Accepted
Reserved --> Charging: matching idTag<br/>plugs in
Reserved --> Available: expiry reached
Reserved --> Available: CancelReservation
Charging --> Available: session endsReserveNow message structure (OCPP 1.6)
{
"connectorId": 1,
"expiryDate": "2026-06-27T15:30:00Z",
"idTag": "USER-12345",
"reservationId": 9876,
"parentIdTag": null
}The fields:
- connectorId. Which connector to reserve.
- expiryDate. When the reservation auto-releases.
- idTag. The user identifier that this reservation is for.
- reservationId. Unique ID for this reservation.
- parentIdTag. Optional, for organizational user hierarchies.
The charger response is just a status:
{ "status": "Accepted" }Or one of: Faulted (connector has a fault), Occupied (already in use), Rejected (generic), Unavailable (connector unavailable for reservations).
OCPP 2.0.1: ReserveNowRequest
The 2.0.1 version uses the idToken structure for user identification:
{
"id": 9876,
"expiryDateTime": "2026-06-27T15:30:00Z",
"idToken": {
"idToken": "USER-12345",
"type": "ISO14443"
},
"connectorType": "cType2",
"evseId": 1
}The connectorType field is new, and it earns its place on chargers with several connector types per EVSE, such as a DC fast charger offering both CCS and CHAdeMO.
What happens during the reservation
Once a reservation is active, the charger enforces it.
Connector state. The connector reports as Reserved (not Available). Users walking up see “Reserved” on the display.
Authorization filtering. When any user presents an idTag, the charger compares to the reservation’s idTag.
- If matches → authorize, start session.
- If doesn’t match → reject (“This charger is reserved”).
Idle handling. If no one shows up, the reservation runs to expiryDate and auto-releases.
Override mechanisms. Some chargers allow the operator to force-release a reservation (e.g., emergency need). Done via CSMS-issued CancelReservation.
CancelReservation
To cancel a reservation before it expires:
OCPP 1.6:
{ "reservationId": 9876 }OCPP 2.0.1:
{ "reservationId": 9876 }Same structure. The charger responds Accepted when the cancellation succeeded, or Rejected when it could not cancel, usually because the reservation was already used or had expired.
The expiry challenge
A practical problem: how long should reservations be?
Too short. User arrives 5 minutes late and the slot is gone.
Too long. Connector sits idle for an hour while a no-show user keeps the reservation.
Common patterns:
- 15-30 minute reservations for short-notice (within the next hour or two).
- Longer reservations only for specific contexts (e.g., book this charger for tomorrow 10am-11am).
- Auto-extend on arrival. If the user plugs in shortly after reservation expires, extend by a few minutes to avoid race conditions.
Network operators tune these based on user behavior. Highway corridor sites with high turnover use short reservations; workplace chargers with predictable schedules can use longer.
Reservation pricing models
A reservation may have its own cost.
Free reservation, normal session price. Simple. Risk: users reserve and don’t show up because there’s no cost to no-shows.
Reservation fee added to session price. “Reserving costs $1, plus normal session pricing.” Discourages frivolous reservations.
No-show fee. Free reservation, but a fee if you don’t show up (charge automatically after expiry without fulfillment). Aligns incentives without front-loading cost.
Reservation-only premium pricing. Reserved sessions cost more per kWh than walk-ins. Less common.
OCPI 2.2 added RESERVATION_TIME as a tariff dimension specifically to express reservation pricing.
Where reservations are actually worth it
Support across public networks is uneven, and it is more useful to understand the deciding factor than to memorise who offers what, because that changes without notice.
The factor is scarcity. A reservation transfers certainty from the operator to one driver, and it costs the operator real utilisation: a held connector earns nothing while it waits, and the holder may not arrive at all. That trade only pays where demand reliably exceeds supply.
That predicts the pattern you actually see:
- Highway corridor sites, where arriving to a full site strands someone, are where reservations earn their cost.
- Destination and workplace charging sits in the middle. Booking appears once a site is popular enough that regulars compete for connectors.
- Shared residential charging often uses a booking system, because the population is fixed, known and repeat, which is exactly when scheduling beats queuing.
- Fleet depots (coming soon) take this furthest and schedule rather than reserve, because the operator knows every vehicle and every departure time in advance.
Where a driver can expect a free connector on arrival, a reservation system is cost without benefit. For whether a specific network supports it, check that operator’s own app or documentation, since this is exactly the kind of fact that changes quarterly.
Common operational issues
A list of things that go wrong with reservations.
Race conditions. User plugs in just as their reservation expires; some chargers fail this race.
Stale reservation state. Reservation was cancelled but the charger never processed the CancelReservation. Connector shows reserved when it isn’t.
Multiple reservations for the same slot. Bug somewhere in the back-end allowed double-booking. One reservation fails when activated.
Cross-protocol confusion. User reserves via app; arrives and presents RFID card. The RFID and the app are different idTags. Reservation doesn’t recognize the RFID. Reservation fails to be honored.
Time zone mismatches. Reservation expiry computed in user’s time zone, sent in UTC, parsed in charger’s time zone. Subtle off-by-hour bugs.
Reservation persists after physical disconnect. Charger is removed, taken offline, but the reservation remains in the CSMS’s view. Phantom reservation.
What CSMSes should do
A few principles for building reservation support.
Idempotent reservation creation. Two requests to create the same reservation should be safe (return the existing one).
Track reservation state per charger. Operations dashboard should show current reservations.
Reconcile after charger reconnect. When a charger comes back online after an outage, sync reservation state.
Handle the unhappy paths. No-shows, cancellations, and expired sessions each need explicit lifecycle handling.
Surface reservation in OCPI. Partner eMSPs need to know about reservations on shared chargers.
Connector-vs-EVSE precision. Reservations should be precise about what’s reserved. A multi-EVSE charger has multiple reservable slots.
What chargers should do
For firmware engineers:
Enforce reservations correctly. Reject non-matching idTags consistently.
Handle expiration cleanly. Auto-release at expiry; don’t require explicit cancellation.
Report reservation state accurately. StatusNotification should show Reserved when reserved; Available when not.
Support concurrent operations. A CancelReservation arriving during a user’s session start should be handled gracefully.
Time-sync rigorously. Reservation expiry checks depend on accurate clock.
User experience considerations
A few UX principles for reservations.
Show realistic expectations. “Reserved” has to mean the charger is genuinely yours. If your stack cannot enforce that reliably, do not offer the feature, because a reservation that fails on arrival is worse than no reservation at all.
Easy cancellation. Users who can’t make it should cancel easily. Reduces no-shows.
Clear time windows. “Reserved 3:00pm-3:30pm” is clearer than “Reserved for 30 minutes from now.”
Notifications. Remind user of upcoming reservation; warn before expiry.
Recover gracefully. If the user arrives after expiry, offer to start a new session normally (don’t error out completely).
The honest summary
OCPP reservation is a well-defined feature that’s optional in implementation and uneven in deployment. Where availability scarcity makes it valuable (highway corridors, popular workplace chargers, apartment shared chargers), reservations matter and need to work reliably. Where availability is plentiful, walk-up is fine and reservation complexity is overhead. Build it carefully when you build it; testing the unhappy paths matters more than the happy path; coordinate with OCPI partners for shared-charger scenarios.