OCPP Reservation: How Reserving a Charger Actually Works

EV charger reservations are one of those features that sound simple — “save a spot for me” — but have real protocol complexity beneath the surface. 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:

1. User requests a reservation via their app for a specific charger at a specific time.
2. eMSP back-end sends an OCPI Command (ReserveNow) to the CPO. The CPO and eMSP roles matter here — the reservation crosses an organizational boundary before it reaches the charger.
3. CSMS receives the Command and sends OCPP ReserveNow to the specific charger.
4. Charger checks availability — is the connector currently Available, or in use?
5. Charger responds with Accepted, Faulted, Occupied, Rejected, or Unavailable.
6. If Accepted, the reservation is active. The charger refuses sessions from other users until expiration or fulfillment.
7. User arrives, plugs in. Their authorization matches the reservation. Charging starts — the same authorization path used by a remote start ^{(coming soon)}, just gated by the reservation.
8. 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 ends

ReserveNow 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 — useful for chargers with multiple connector types per EVSE (e.g., a DC fast charger with 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 with Accepted (cancellation succeeded) or Rejected (couldn’t cancel — possibly already used or 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.

Real-world coverage

Reservation adoption is uneven across the EV charging ecosystem.

Tesla Supercharger: historically no reservations, first-come-first-served. Recent moves toward limited reservation capability.

Electrify America, EVgo: offer reservations through their apps at participating sites. Coverage growing.

Smaller networks: vary. Some have full reservation support; some don’t bother.

Fleet depots: typically have full reservation/scheduling support — it’s how depots coordinate vehicle charging.

Workplace charging: often has reservation systems for popular sites.

Apartment charging: common to have reservation systems when chargers are shared among residents.

The pattern: where availability is genuinely scarce, reservations matter. Where availability is plentiful, walk-up is fine.

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, expired sessions — all need clear 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” should mean “this charger is yours” — if it’s not enforced reliably, don’t offer the feature.

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.