ChargeBridge · OCPI roaming and clearing hub
Connect once. Decide scope. Settle per period.
ChargeBridge is the hub where charge point operators and e-mobility service providers meet over a single OCPI connection. Which partner sees what is your explicit decision; every session becomes a CDR and every CDR enters a settlement window.
Roles
Who connects
Three roles, one connection. A party can be CPO and eMSP at the same time; the hub keeps the two role contexts apart.
CPO
locations · tariffs · sessions · cdrs →For charge point operators
Publish your locations and tariffs once; decide per partner which eMSP sees which site; receive sessions, CDRs and settlement statements from one place.
Partners in this role ask for
- Reach drivers of several eMSP apps without a separate integration for each
- Keep control of which sites and tariffs each partner can see
eMSP
← tokens · commands · authorizeFor 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.
Partners in this role ask for
- Show more chargers in the app without integrating each network
- Authorize drivers in real time at partner chargers
NSP
locations · tariffs (receiver only)For navigation and data providers
Receive locations, status and tariffs that CPOs choose to publish to you; no sessions, CDRs or settlement, because you neither operate chargers nor sell to drivers.
Partners in this role ask for
- Show accurate charger availability in a map or vehicle product
- Receive one feed instead of scraping or integrating networks one by one
Architecture
Three layers, one connection
Roaming is not only data exchange: scope decisions, protocol compatibility and the money flow have to work at the same time. The hub keeps the three apart.
- SCOPE 01
Scope
You decide which location is visible to which partner. Sharing sets, per-partner relationships and publish gates; the default is closed, and every change is written to an audit ledger.
sharing set → relationship → publish gate
How the hub works → - PROTOCOL 02
Protocol
OCPI 2.2.1 and 2.3.0 side by side. Version negotiation, the credential handshake and the token lifecycle are handled hub-side; a partner on another version stops being your problem.
versions → credentials → Token B/C
OCPI modules → - SETTLEMENT 03
Settlement
CDR validation, settlement windows, bilateral netting and a hash-chained ledger. Disputes surface before close; the hub fee is a separate line and is never netted.
CDR → window → statement → obligation
Settlement and clearing →
Evidence
What the hub does, with evidence
Every headline claim on this site is bound to an evidence record: a source review, a document or a test suite. Each record says what it supports and what it does not show.
Evidence records →- 01
One OCPI connection to the hub replaces a bilateral integration with every partner; which partner sees what remains your explicit decision.
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 →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
- 02
OCPI 2.2.1 and 2.3.0 side by side; a partner on a different version is translated hub-side.
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 →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
- 03
Every CDR enters a settlement window; netting statements come out of a hash-chained ledger. Invoicing starts with the financial go-live gate.
Inspect evidence
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
All evidence records →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
- 04
Built for Türkiye’s regulatory reality: the fields local reporting and tax rules need travel with the CDR as an OCPI extension.
Inspect evidence
All evidence records →Türkiye CDR extension (tr-cdr-additionals)· Source code review
A dedicated controller and integration profile carry the utility rate in TRY/kWh, VAT breakdown and reporting identifiers next to each CDR. The underlying OCPI-TR custom module specification (v1.0.0, January 2026) was authored by ZES; E-Gridium implements it as published and credits ZES for the work.
Supports:That the Türkiye profile exists as an OCPI extension on both sender and receiver side.
Does not show:Regulatory acceptance by any authority; the fields are what the parties need for their own reporting.
Source: OCPI-TR Custom Modules specification v1.0.0 (ZES, 19 January 2026) and the hub source repository (private) · Verified4 October 2026
12
services
593
migrations
87
ADRs
~1,500
test files
83
OpenAPI paths
Twelve services, 593 migrations, 87 architecture decisions and about 1,500 test files: the hub is engineered and documented, and the numbers describe the codebase, not the traffic.
Inspect evidence
Engineering footprint of the hub· Source code review
Twelve services in one monorepo (OCPI adapter, clearing platform, identity, roaming mesh, PKI, map data, sandbox, ops MCP, mocks and migrations), 593 database migrations, 87 architecture decision records, about 1,500 test files, and three OpenAPI documents with 83 paths in total.
Supports:That the hub is an engineered, documented system rather than a prototype.
Does not show:Production scale, partner counts or service levels; counts describe the codebase, not the traffic.
Source: Hub source repository, counted on 4 October 2026 · Verified4 October 2026
Automated test suite· Test suite
About 1,500 test files across the OCPI adapter, clearing platform, identity service, roaming mesh and hub portal: unit, contract, end-to-end, property-based and mutation tests.
Supports:That protocol flows and settlement logic are covered by automated tests.
Does not show:On which release and date the suite last passed; a dated run report will be published when available.
Source: Hub source repository, test directories (count of 4 October 2026) · Verified4 October 2026
Protocol
Connect in four calls
The OCPI 2.2.1 credentials handshake runs hub-side exactly as the standard describes it: version discovery, module endpoints, credential exchange. The fourth step is in the portal, not the protocol, and it is the one that actually opens data flow.
- 01
Discover versions
GET /ocpi/versions · Authorization: Token <TOKEN_A>
- 02
Read module endpoints
GET /ocpi/2.2.1 · Authorization: Token <TOKEN_A>
- 03
Exchange credentials
POST /ocpi/2.2.1/credentials · body: your credentials + TOKEN_B
- 04
Accept relationships
hub portal · partner relationship · both sides accept
Where the service stands
Two gates: technical open, financial in dry-run
Technical gate
Handshake, data flow, statements
Financial gate
Data processing agreements, registrations, e-invoicing
Technical connectivity is live for onboarding partners: handshake, data flow and settlement statements. Settlement runs in dry-run until the financial go-live gate closes (data processing agreements with every partner, regulatory registrations, e-invoicing). No partner names or counts are published on this site; connected parties are visible to each other through the hub directory.
Türkiye
Built for Türkiye’s regulatory reality
The fields local reporting and tax rules need travel with the CDR as an OCPI extension. European hubs bolt this on afterwards; the hub started there.
- Utility rate
- The active energy unit price valid for the location on the day of the session, in TRY per kWh with four decimals. Where a location has a time-of-use tariff, the session-weighted average is expected.
- VAT
- The VAT-inclusive field is optional and is never derived when absent; the record is then marked as excluding VAT only. A VAT-inclusive value below the exclusive value is rejected.
- Corrections
- The object is immutable in the specification. On the receiving side the hub applies versioned append: a newer last_updated for the same CDR key is a correction; the latest version counts and earlier ones stay as an audit trail. As a sender the hub never re-sends an object.
Company
E-Gridium and Electroop
Electroop and E-Gridium are separate companies operating under common ownership. ChargeBridge is an E-Gridium product.
The hub is operated by E-Gridium independently of which charging software a partner runs; any compliant OCPI implementation can connect.
How it proceeds
- 01Apply with your role and versions endpoint
- 02Sign the participation agreement and DPA
- 03Handshake in the sandbox, then accept relationships