Who the parties are
CPO, Charge Point Operator. Runs the chargers. Owns the hardware, the locations and the energy delivery, and produces the record of what was delivered. More. eMSP, e-Mobility Service Provider. Has the drivers. Issues the card or the app, authorizes a charge, and bills the person at the end. Often written EMSP in code and API fields, including ours. Hub. Sits between many CPOs and many eMSPs so each one integrates once instead of n times. TheHUB role appears in the Role enum of OCPI 2.2 and 2.2.1 only: 2.1.1 has no
role enum at all and never names a hub, and 2.3.0 drops the value. ChargerDojo tests 2.1.1, 2.2,
2.2.1 and 2.3.0 regardless of that.
PTP, Payment Terminal Provider. Operates the card readers that let someone pay at the charger
without an app or a contract. Relevant only if you are testing the Payments modules.
CSMS, Charging Station Management System. The platform a charger talks to over OCPP. It is
not an OCPI party, and it appears in these guides only where a journey compares what your CSMS
believes with what you report over OCPI.
What moves between them
Session. A charge, from the moment it is set up to the moment it closes. Its initial state isPENDING, which the spec is careful to say “might never become an active session”, so a session
existing is not the same as energy flowing. Walkthrough.
CDR, Charge Detail Record. The final, immutable record of one completed charge: how much
energy, how long, what it cost. The thing the bill is built from, and the thing a duplicate of
causes a driver to be charged twice.
What that failure looks like.
Token. How a driver is identified: an RFID card, an app, a contract id. Not to be confused
with the credentials tokens below, which are how two platforms authenticate to each other.
Tariff. What a charge costs, published by the CPO so the eMSP can show a price before the
driver plugs in.
Location. A physical site, its charge points, their EVSEs and their connectors. An EVSE is
not a charge point: the spec calls it “an independently operated and managed part of a Charge
Point that can deliver energy to one EV at a time”, and a charge point has one or more. Modelling
them as the same thing is what produces wrong evse_uid values.
How two platforms connect
Module. One area of the protocol with its own endpoints: Locations, Sessions, CDRs, Tariffs, Tokens, Commands, Credentials, and more in later versions. A version advertises the modules it implements, and we only run a suite for a module the version defines. What the peer advertised is handled one level down: a check against a module they do not implement grades nothing rather than failing them. Versions endpoint. The one URL you exchange to begin. Everything else is discovered from it: it lists the OCPI versions a platform speaks, each pointing at a detail document that lists that version’s module endpoints. Sender and receiver. From 2.2 onward each module has two interfaces and a party implements one, the other, or both. The names describe who owns the data, not who makes the call: the spec calls SENDER the “Interface implemented by the owner of data, so the Receiver can Pull information from the data Sender/owner”. So the SENDER interface is usually the read surface, and pushing into a peer means calling their RECEIVER. A peer advertising a module for one interface has generally said it does not implement the other, with one exception you will meet immediately: Credentials. The spec says the role property “is not relevant as this module is the same for all roles”, so do not read a partner’scredentials/SENDER as a refusal to accept your registration POST.
Token A, B and C. The three credentials tokens of the registration handshake, and the
commonest source of a 401 that looks like something else. Token A is the registration token
the receiving party issues out of band; once the exchange finishes it may no longer be used.
Then each side generates one token and uses the other’s, which is the part people get
backwards. The sender generates Token B and POSTs it; the receiver stores Token B and uses it
for its requests back. The receiver generates Token C and returns it; the sender uses Token C
for everything afterwards. If a partner is still sending Token A after registering, that is why
everything returns 401. The handshake.
country_code and party_id. The two fields that identify a party, together. From 2.2 they
also travel as routing headers, though not on every request, and never on Credentials, Versions or
HubClientInfo, which are point-to-point. OCPI 2.1.1 has no routing headers at all. Your partner
needs both to address you.
Words that only mean something here
Sandbox. Our built-in OCPI peer. A real implementation answering real HTTP, free to run against at every tier. Its registration is short-circuited rather than handshaken over loopback, which our own SSRF guard would refuse. A green sandbox run proves the tool works, not that your implementation does. Where the free line falls. Connection, sometimes called a target. One partner endpoint you test against, plus the credentials for it. Conformance check. One rule asserted against one exchange. Passes, fails, or grades nothing. Scenario. A story walked end to end, chaining its own output from step to step, rather than one rule against one exchange. Run the same way as a suite, never part of a sweep, and covered by its own stricter falsifiability sweep. See Read your report. Charging journey. A timed run of a whole charging story against a real endpoint, with disturbances injected and four graded lanes. Minutes, not seconds. Run one. Journey pack. A named group of journeys that belong together, such as core charging or roaming. It picks which stories are on the menu, not how any of them runs. Coverage depth. How hard a journey pushes:happy-path walks the story as it should go,
edge-cases adds the awkward ones, adversarial tries to break you.
Load run. A journey run at volume to measure behaviour under concurrency. Not a conformance
result, and meaningless over a tunnel, which it measures as much as it measures you.
Warning. A rule the spec only recommends that your partner declined. Never a failure, and
never a reason to fail a build. Why.
Unobservable. A check that graded nothing, because the response carried nothing to grade or
no request was sent. Not a pass and not a failure, counted separately so an empty answer never
reads as a clean one.