Skip to main content
A connection is a partner OCPI endpoint you test against. Setting one up is two API calls: create it, then register it. Creation records who you are, who they are, and the token they gave you. Registration performs the live OCPI credentials handshake, and it is the step that usually goes wrong.

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

This runs the real OCPI credentials handshake against the partner. It is not a simulation and not an assertion against a stored token: the tester reads their versions endpoint with Token A, posts its own credentials, and receives the token it will use for every subsequent call. On success the connection’s 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

Connections are owner scoped: you see your own, plus the built-in sandbox targets. A connection id that belongs to someone else answers 404.

Next

Run a conformance suite against the registered connection.