What you need from your partner
Two things, and they come from them, not from us:
Token A is not something you generate. The OCPI specification is explicit that it is
created by the receiving party and passed to you “in a secure way that is outside the
scope of this protocol”: an email, a portal, a phone call. If your partner asks you for
Token A, one of you has the roles the wrong way round, and it is worth settling that
before you write any code.
Create the connection
You get back
201 with the connection, its _id, and status: "pending". Token fields
are never returned, by us or in any report.
Pick the version they actually run, not the newest one
The most common setup mistake is selecting 2.2.1 because it sounds current when the partner is on 2.1.1. Every subsequent failure will then be a version mismatch wearing the costume of a protocol bug. If you do not know what they run, ask, or read their versions endpoint. OCPI 2.1.1 is still in wide production use, and there is no shame in it.The credentials token is transported differently across versions. OCPI 2.1.1 sends it
raw; from 2.2 onwards it is Base64 encoded. Get the version wrong and authentication
fails on the very first request, with an error that looks nothing like a version
problem. The tester handles the encoding for you, but only if you told it the right
version.
Register: the live credentials handshake
status becomes registered. On failure it
records lastError, and that error is the thing worth reading.
Registration is where OCPI integrations get stuck, and the failures follow a pattern:
a side keeps presenting the dead registration token after the exchange, a partner never
fetches your endpoints, or the token encoding does not match the version. The
troubleshooting page walks each one.
Read your connections
404.