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.

Apply to connect How the hub works →

Who connects

CPO

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

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.

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

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

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.

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.
How the hub works →
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.
OCPI modules →
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.
Settlement and clearing →

What the hub does, with evidence

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
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 →
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
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 →
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
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
All evidence records →
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
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
All evidence records →

Evidence records →

Where the service stands

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.

Onboarding and sandbox → Settlement and clearing →

Türkiye