OCPI 2.2.1 Simulator
OCPI is how a CPO and an eMSP talk so a driver can roam. Pick a scenario and step through the real HTTP requests and responses — the method, the path, the headers, and the envelope that wraps every reply.
status_code Space play · ← → step · R reset How to read an OCPI exchange
OCPI is REST, not a socket protocol — so every step is an HTTP request or its response. Two things trip people up, and the simulator makes both visible:
- The response envelope. Every reply wraps its payload
in
{ data, status_code, status_message, timestamp }. The HTTP status tells you the transport worked; thestatus_codetells you whether OCPI is happy. An HTTP200can carry a2003error — always read both. - Sender = data owner. The Sender is the party that owns the data; the Receiver consumes it. The CPO is the Sender of Locations, Sessions, CDRs, and Tariffs; the eMSP is the Sender of Tokens. Build the wrong half of that and nothing lines up.
What each scenario shows
- Registration handshake — the three-token dance (A, B, C) that has to happen before any business data flows.
- Locations — the eMSP pulling a charge point, and where
statusactually lives (on the EVSE, not the connector). - Sessions — a live session pushed with
PUT, then merged withPATCH. - Commands — a remote START, and why Commands are asynchronous (an immediate ack, then a callback).
- CDR — the final, immutable billing receipt.
- The error envelope — HTTP 200 that is not, in fact, a success.
Want the full reference — all 12 modules, the Base64 auth header, and the gotchas that reach production? Read What is OCPI, the Locations module and Sessions module in depth, or browse every OCPI guide. For the station side of the story, try the OCPP 2.0.1 simulator.
This is a teaching aid: the exchanges are canned, accurate sample messages, not a live connection to any platform. It runs entirely in your browser.
Frequently asked questions
What is an OCPI sandbox?
An OCPI sandbox lets you exercise the OCPI request/response flow without a live roaming partner. This one steps through accurate OCPI 2.2.1 HTTP exchanges — the credentials handshake, Locations, Sessions, Commands, and CDRs — so you can see the method, path, headers, and the envelope of each reply.
Are these real OCPI 2.2.1 messages?
Yes. The object shapes, field names (snake_case, as in the spec), status codes, and the response envelope all match OCPI 2.2.1. Tokens and URLs are illustrative placeholders.
What is the OCPI response envelope?
Every OCPI response wraps its payload in { data, status_code, status_message, timestamp }. The HTTP status tells you the transport worked; the status_code tells you whether OCPI itself is happy — 1000 is success, 2xxx a client error, 3xxx a server error.
Why can an HTTP 200 still be an OCPI error?
Because the transport and the application layer are separate. A well-formed request over a valid connection returns HTTP 200 even when the OCPI operation failed — the failure shows up as a non-1000 status_code inside the envelope. Always read both.
Does it cover the credentials handshake?
Yes. The registration scenario walks the full three-token handshake (Token A, B, and C) across Versions and Credentials, including why Token A is single-use and how the parties authenticate afterwards.