> ## Documentation Index
> Fetch the complete documentation index at: https://docs.chargerdojo.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Glossary

> The OCPI and ChargerDojo terms these guides use: CPO, eMSP, CDR, Token A, sender and receiver, module, and the words that only mean something here.

These guides assume some vocabulary. This page is the shortest version of it. For the protocol
itself, rather than the words, the [Learn section](https://chargerdojo.com/learn/) is free and
goes much deeper.

## 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](https://chargerdojo.com/learn/ocpi-explained/).

**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. The `HUB` 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
is `PENDING`, 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](https://chargerdojo.com/learn/charging-session/).

**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](https://chargerdojo.com/learn/scenarios/charged-twice/).

**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's
`credentials/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](/guide/connect-a-partner).

**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](/guide/what-is-free).

**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](/guide/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](/guide/run-a-charging-journey).

**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](/guide/read-your-report).

**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.