Partners · For eMSPs

For e-mobility service providers

Receive locations, live status and tariffs from every CPO you have a relationship with; push your tokens once; start, stop and reserve through a single command channel.

Apply to connect Onboarding and sandbox →

You send: tokens · commands · chargingprofiles · bookings · tokens (groups)
You receive: locations · tariffs · sessions · cdrs · payment
You keep: the driver relationship and the authorization decision

OCPI credentials handshake: versions, version details, credentials exchange and the relationship accepted by both sides. — The handshake establishes identity; data flows once the relationship is accepted by both sides.

For eMSPs

Partners in this role ask for

Four requests, four answers. Each has its counterpart in the module table and the portal views below.

01
Show more chargers in the app without integrating each network
02
Authorize drivers in real time at partner chargers
03
Get one statement per period across all CPO partners
04
Keep the driver relationship and the app in your own hands

Module

Modules you use

Direction is the flow between you and the hub in this role. Status says what the service covers; the evidence level says what the claim rests on.

OCPI modules →

Module	Version	Direction	Summary	Status	Evidence
credentials	OCPI 2.2.1	Sender and receiver	Registration handshake and token lifecycle between a partner and the hub.	Offered	1/4 Present in source code Inspect evidence OCPI 2.2.1 route table· Source code review The OCPI adapter mounts controllers for credentials, locations, sessions, cdrs, tariffs, tokens, commands, chargingprofiles and hubclientinfo under the 2.2.1 version endpoint, with auth, idempotency, rate-limit and audit middleware. Supports:That the nine 2.2.1 modules are implemented and routed in the hub. Does not show:Interoperability with a specific partner’s implementation; that is established per partner in the sandbox and the acceptance checklist. Source: ChargeBridge hub source repository (private), reviewed on the date given · Verified4 October 2026 Fail-closed partner relationships· Source code review No location, tariff, session, CDR or token flows unless an explicitly accepted, active partner relationship exists between the two parties; publish scope defaults to deny and changes are written to an audit ledger. Supports:That a completed credentials handshake does not open data flow and that scope is an explicit, auditable decision. Does not show:Contractual data-sharing permissions; those come from the signed agreement and DPA. Source: ChargeBridge hub source repository (private), reviewed on the date given · Verified4 October 2026 Partner sandbox· Source code review Sandbox routes in the OCPI adapter and a mock partner and charger simulator let a partner complete the handshake and exercise each module against test data before onboarding. Supports:That a test environment is part of onboarding. Does not show:Self-service sign-up; sandbox credentials are issued after the application is reviewed. Source: ChargeBridge hub source repository (private), reviewed on the date given · Verified4 October 2026 All evidence records →
locations	OCPI 2.2.1	Receiver	Locations, EVSEs and connectors with live status.	Offered	1/4 Present in source code Inspect evidence OCPI 2.2.1 route table· Source code review The OCPI adapter mounts controllers for credentials, locations, sessions, cdrs, tariffs, tokens, commands, chargingprofiles and hubclientinfo under the 2.2.1 version endpoint, with auth, idempotency, rate-limit and audit middleware. Supports:That the nine 2.2.1 modules are implemented and routed in the hub. Does not show:Interoperability with a specific partner’s implementation; that is established per partner in the sandbox and the acceptance checklist. Source: ChargeBridge hub source repository (private), reviewed on the date given · Verified4 October 2026 Fail-closed partner relationships· Source code review No location, tariff, session, CDR or token flows unless an explicitly accepted, active partner relationship exists between the two parties; publish scope defaults to deny and changes are written to an audit ledger. Supports:That a completed credentials handshake does not open data flow and that scope is an explicit, auditable decision. Does not show:Contractual data-sharing permissions; those come from the signed agreement and DPA. Source: ChargeBridge hub source repository (private), reviewed on the date given · Verified4 October 2026 All evidence records →
tariffs	OCPI 2.2.1	Receiver	Tariff definitions with price components and restrictions.	Offered	1/4 Present in source code Inspect evidence OCPI 2.2.1 route table· Source code review The OCPI adapter mounts controllers for credentials, locations, sessions, cdrs, tariffs, tokens, commands, chargingprofiles and hubclientinfo under the 2.2.1 version endpoint, with auth, idempotency, rate-limit and audit middleware. Supports:That the nine 2.2.1 modules are implemented and routed in the hub. Does not show:Interoperability with a specific partner’s implementation; that is established per partner in the sandbox and the acceptance checklist. Source: ChargeBridge hub source repository (private), reviewed on the date given · Verified4 October 2026 Fail-closed partner relationships· Source code review No location, tariff, session, CDR or token flows unless an explicitly accepted, active partner relationship exists between the two parties; publish scope defaults to deny and changes are written to an audit ledger. Supports:That a completed credentials handshake does not open data flow and that scope is an explicit, auditable decision. Does not show:Contractual data-sharing permissions; those come from the signed agreement and DPA. Source: ChargeBridge hub source repository (private), reviewed on the date given · Verified4 October 2026 All evidence records →
sessions	OCPI 2.2.1	Receiver	Charging sessions in progress, from start to end.	Offered	1/4 Present in source code Inspect evidence OCPI 2.2.1 route table· Source code review The OCPI adapter mounts controllers for credentials, locations, sessions, cdrs, tariffs, tokens, commands, chargingprofiles and hubclientinfo under the 2.2.1 version endpoint, with auth, idempotency, rate-limit and audit middleware. Supports:That the nine 2.2.1 modules are implemented and routed in the hub. Does not show:Interoperability with a specific partner’s implementation; that is established per partner in the sandbox and the acceptance checklist. Source: ChargeBridge hub source repository (private), reviewed on the date given · Verified4 October 2026 Fail-closed partner relationships· Source code review No location, tariff, session, CDR or token flows unless an explicitly accepted, active partner relationship exists between the two parties; publish scope defaults to deny and changes are written to an audit ledger. Supports:That a completed credentials handshake does not open data flow and that scope is an explicit, auditable decision. Does not show:Contractual data-sharing permissions; those come from the signed agreement and DPA. Source: ChargeBridge hub source repository (private), reviewed on the date given · Verified4 October 2026 All evidence records →
cdrs	OCPI 2.2.1	Receiver	Charge detail records: the billable record of a session.	Offered	2/4 Real screen or document Inspect evidence OCPI 2.2.1 route table· Source code review The OCPI adapter mounts controllers for credentials, locations, sessions, cdrs, tariffs, tokens, commands, chargingprofiles and hubclientinfo under the 2.2.1 version endpoint, with auth, idempotency, rate-limit and audit middleware. Supports:That the nine 2.2.1 modules are implemented and routed in the hub. Does not show:Interoperability with a specific partner’s implementation; that is established per partner in the sandbox and the acceptance checklist. Source: ChargeBridge hub source repository (private), reviewed on the date given · Verified4 October 2026 Settlement window state machine· Source code review The clearing platform moves each settlement window through OPEN, GRACE_PERIOD, RECONCILING and CLOSED; late CDRs enter during the grace period and disputes surface before close. Supports:That settlement periods, netting statements and payment obligations are produced by the platform. Does not show:That money has moved between partners through the hub: settlement runs in dry-run until the financial go-live gate closes, and invoicing is fenced until then. Source: ChargeBridge hub source repository (private), reviewed on the date given · Verified4 October 2026 Hash-chained settlement ledger· Source code review Ledger entries are chained by hash so a statement can be re-verified against its inputs; hub fees are booked as separate lines for each party and never netted against roaming amounts. Supports:Tamper-evidence of the ledger and the “hub fee outside netting” rule. Does not show:Fee rates or splits; those are in the participation agreement, not on this site. Source: ChargeBridge hub source repository (private), reviewed on the date given · Verified4 October 2026 Fail-closed partner relationships· Source code review No location, tariff, session, CDR or token flows unless an explicitly accepted, active partner relationship exists between the two parties; publish scope defaults to deny and changes are written to an audit ledger. Supports:That a completed credentials handshake does not open data flow and that scope is an explicit, auditable decision. Does not show:Contractual data-sharing permissions; those come from the signed agreement and DPA. Source: ChargeBridge hub source repository (private), reviewed on the date given · Verified4 October 2026 Settlement architecture: agreements, windows, statements, obligations· Document Bilateral, versioned agreements define cycle, grace period, dispute window, fee allocation, payment automation and FX policy; windows move OPEN → GRACE_PERIOD → RECONCILING → CLOSED; statements move GENERATED → PUBLISHED → ACKNOWLEDGED and are hub-signed; obligations carry debtor, creditor, amount and due date. Supports:The structure described on the settlement page. Does not show:Any rate, amount or that real money has moved; payment automation beyond manual mode is configured per partner after the financial go-live gate. Source: Hub repository, docs/architecture/settlement (domain model, state machines, cycle computation) · Verified4 October 2026 All evidence records →
tokens	OCPI 2.2.1	Sender	Driver tokens (RFID, app) and real-time authorization.	Offered	1/4 Present in source code Inspect evidence OCPI 2.2.1 route table· Source code review The OCPI adapter mounts controllers for credentials, locations, sessions, cdrs, tariffs, tokens, commands, chargingprofiles and hubclientinfo under the 2.2.1 version endpoint, with auth, idempotency, rate-limit and audit middleware. Supports:That the nine 2.2.1 modules are implemented and routed in the hub. Does not show:Interoperability with a specific partner’s implementation; that is established per partner in the sandbox and the acceptance checklist. Source: ChargeBridge hub source repository (private), reviewed on the date given · Verified4 October 2026 Fail-closed partner relationships· Source code review No location, tariff, session, CDR or token flows unless an explicitly accepted, active partner relationship exists between the two parties; publish scope defaults to deny and changes are written to an audit ledger. Supports:That a completed credentials handshake does not open data flow and that scope is an explicit, auditable decision. Does not show:Contractual data-sharing permissions; those come from the signed agreement and DPA. Source: ChargeBridge hub source repository (private), reviewed on the date given · Verified4 October 2026 Retention sweep for token material· Source code review Hashed token data and encrypted credentials are deleted as soon as their retention time expires; the sweep runs on a schedule and is the most conservative setting available. Supports:The delete-on-expiry rule stated on the trust page. Does not show:A data-controller’s own retention obligations; those are set in each DPA. Source: ChargeBridge hub source repository (private), reviewed on the date given · Verified4 October 2026 All evidence records →
commands	OCPI 2.2.1	Sender	Remote start, stop, reserve and unlock, relayed through the hub.	Offered	1/4 Present in source code Inspect evidence OCPI 2.2.1 route table· Source code review The OCPI adapter mounts controllers for credentials, locations, sessions, cdrs, tariffs, tokens, commands, chargingprofiles and hubclientinfo under the 2.2.1 version endpoint, with auth, idempotency, rate-limit and audit middleware. Supports:That the nine 2.2.1 modules are implemented and routed in the hub. Does not show:Interoperability with a specific partner’s implementation; that is established per partner in the sandbox and the acceptance checklist. Source: ChargeBridge hub source repository (private), reviewed on the date given · Verified4 October 2026 All evidence records →
chargingprofiles	OCPI 2.2.1	Sender	Smart-charging profiles set and read through the hub.	Offered	1/4 Present in source code Inspect evidence OCPI 2.2.1 route table· Source code review The OCPI adapter mounts controllers for credentials, locations, sessions, cdrs, tariffs, tokens, commands, chargingprofiles and hubclientinfo under the 2.2.1 version endpoint, with auth, idempotency, rate-limit and audit middleware. Supports:That the nine 2.2.1 modules are implemented and routed in the hub. Does not show:Interoperability with a specific partner’s implementation; that is established per partner in the sandbox and the acceptance checklist. Source: ChargeBridge hub source repository (private), reviewed on the date given · Verified4 October 2026 All evidence records →
bookings	OCPI 2.3.0	Sender	Reservation of a charger for a time window, create and cancel.	Offered	1/4 Present in source code Inspect evidence OCPI 2.3.0 route table· Source code review A separate 2.3.0 version endpoint routes bookings, parking bays, payment sessions and token groups, with a translation layer between 2.2.1 and 2.3.0 partners. Supports:That OCPI 2.3.0 objects are accepted and relayed and that mixed-version partners can be connected. Does not show:Production use of 2.3.0 with a named partner; payment-session objects do not make the hub a payment institution. Source: ChargeBridge hub source repository (private), reviewed on the date given · Verified4 October 2026 All evidence records →
tokens (groups)	OCPI 2.3.0	Sender	Grouping of tokens for fleet and shared-account scenarios.	Offered	1/4 Present in source code Inspect evidence OCPI 2.3.0 route table· Source code review A separate 2.3.0 version endpoint routes bookings, parking bays, payment sessions and token groups, with a translation layer between 2.2.1 and 2.3.0 partners. Supports:That OCPI 2.3.0 objects are accepted and relayed and that mixed-version partners can be connected. Does not show:Production use of 2.3.0 with a named partner; payment-session objects do not make the hub a payment institution. Source: ChargeBridge hub source repository (private), reviewed on the date given · Verified4 October 2026 All evidence records →
payment	OCPI 2.3.0	Receiver	Payment-session objects for ad-hoc (card) charging as defined in OCPI 2.3.0.	Offered	1/4 Present in source code Inspect evidence OCPI 2.3.0 route table· Source code review A separate 2.3.0 version endpoint routes bookings, parking bays, payment sessions and token groups, with a translation layer between 2.2.1 and 2.3.0 partners. Supports:That OCPI 2.3.0 objects are accepted and relayed and that mixed-version partners can be connected. Does not show:Production use of 2.3.0 with a named partner; payment-session objects do not make the hub a payment institution. Source: ChargeBridge hub source repository (private), reviewed on the date given · Verified4 October 2026 All evidence records →

Technical prerequisites

What has to be ready on your side before the handshake

Three lists: what every partner needs, this role’s module interfaces and network behaviour. All of it is exercised in the sandbox first, against the charger simulator.

01 · Every partner

Versions endpoint (GET /ocpi/versions) and version details (GET /ocpi/2.2.1 or /ocpi/2.3.0)
Credentials module, sender and receiver interfaces
HTTPS with TLS 1.2 or newer; endpoints reachable from the hub without allow-listing

02 · Interfaces for this role

locationsReceiver
tariffsReceiver
sessionsReceiver
cdrsReceiver
tokensSender + real-time authorize
commandsSender

03 · Network behaviour

Responses within 10 seconds (connection timeout)
Idempotent handling of retried pushes
A sandbox round before production: handshake, then each module against the charger simulator

The full handshake sequence and the sandbox: Onboarding and sandbox →

Portal

What you see in the hub portal

Every view is scoped to your party; you never see another partner’s records. Role contexts are kept apart: even when one party runs both roles, views and statements never mix.

Inspect evidence

Hub portal views per role· Source code review

The portal route table defines hub-operator views (directory, map, settlement windows, approvals, partners, contract queue, aggregators, operations, stuck work) and partner views (my statements, my records, my contract, roaming, data quality) with CPO-only sharing sets and tariffs and eMSP-only tokens, sessions, reservations and commands.

Supports:The portal views listed on the role pages.

Does not show:What a given partner sees in production; access is scoped per party. Real screens will be added as separate product-flow records.

Source: ChargeBridge hub source repository (private), reviewed on the date given · Verified4 October 2026

All evidence records →

01My tokens
02My sessions
03My reservations
04My commands and results
05My settlement statements
06My records: CDRs received
07My contract and relationships

Two gates

What you need

The technical gate opens the handshake and data flow; the financial gate opens real money. This list does not replace the participation agreement.

Technical gate

Per partner

For the handshake and data flow

Signed roaming participation agreement and data processing agreement
Legal name and tax number
An OCPI versions endpoint reachable from the hub and a Token A for the handshake
Receiver implementations for locations, tariffs, sessions and CDRs; sender for tokens and commands
Real-time authorize endpoint for tokens

Financial gate

Once for the hub

For real money to flow

Collection and invoicing details as set out in the agreement

Until the financial gate closes, settlement statements are produced in dry-run and no invoice is issued: you see the amounts, no money moves.

Sequence

How it proceeds

01
Application and agreement

You apply with your role and versions endpoint; the agreement and DPA are signed; your party is created in the hub directory.
02
Sandbox and handshake

Credentials are exchanged against the sandbox; token push, authorize and the command round trip are exercised with the charger simulator.
03
Relationships

Each CPO relationship is accepted by both sides; from then on that CPO’s shared locations, tariffs and status reach you.
04
Sessions and statements

Your drivers charge at partner sites; sessions and CDRs arrive through the hub; each settlement window closes with one statement across all your CPO partners.

Commands with ownership checks

A start, stop, reserve or unlock command is routed to a charger only if your relationship with that CPO includes the location. Results come back asynchronously and are visible in your portal view with the full trace.

1/4 Present in source code

Inspect evidence

Fail-closed partner relationships· Source code review

No location, tariff, session, CDR or token flows unless an explicitly accepted, active partner relationship exists between the two parties; publish scope defaults to deny and changes are written to an audit ledger.

Supports:That a completed credentials handshake does not open data flow and that scope is an explicit, auditable decision.

Does not show:Contractual data-sharing permissions; those come from the signed agreement and DPA.

Source: ChargeBridge hub source repository (private), reviewed on the date given · Verified4 October 2026

All evidence records →

Tokens and retention

Token material pushed to the hub is hashed; encrypted credentials and hashes are deleted as soon as their retention time expires. Authorization decisions remain yours: the hub relays the real-time authorize call to you.

1/4 Present in source code

Inspect evidence

Retention sweep for token material· Source code review

Hashed token data and encrypted credentials are deleted as soon as their retention time expires; the sweep runs on a schedule and is the most conservative setting available.

Supports:The delete-on-expiry rule stated on the trust page.

Does not show:A data-controller’s own retention obligations; those are set in each DPA.

Source: ChargeBridge hub source repository (private), reviewed on the date given · Verified4 October 2026

All evidence records →

Frequently asked questions

Do I get every CPO on the hub automatically?

No. A relationship has to be accepted by both you and the CPO. Discovery of who is connected comes through hubclientinfo; the commercial step is yours.

Can I run both roles?

Yes. A party can be CPO and eMSP at the same time; the hub keeps the two role contexts and their statements apart.

Is the hub a payment institution?

No. The hub produces netting statements and payment obligations; money moves between the parties through the collection method set in the agreement. Card data never passes through the hub.

How it proceeds

01Apply with your role and versions endpoint
02Sign the participation agreement and DPA
03Handshake in the sandbox, then accept relationships

Connect your network or app once; decide the rest per partner.

Apply to connect Onboarding and sandbox →

For e-mobility service providers

Partners in this role ask for

Modules you use

What has to be ready on your side before the handshake

What you see in the hub portal

What you need

For the handshake and data flow

For real money to flow

How it proceeds

Application and agreement

Sandbox and handshake

Relationships

Sessions and statements

Commands with ownership checks

Tokens and retention

Frequently asked questions

Connect your network or app once; decide the rest per partner.