Hub · OCPI modules
OCPI modules: what is routed, in which direction, with what evidence
Every row is verified against the route tables in the hub source; the verification date is on the row. The status vocabulary has three words and no others. Direction says who produces the module object and who receives it; the evidence level says what the claim rests on.
Status vocabulary
- Offered
Routed by the hub for connected partners.
- Offered, settlement in dry-run
Produced by the platform; no invoice until the financial go-live gate closes.
- Not offered
Not part of the service; stated so nobody assumes it.
The third word is written down too: what is not offered is listed so nobody assumes it.
14
modules routed
9
OCPI 2.2.1
4
OCPI 2.3.0
1
Türkiye extension
2
explicitly not offered
Direction map
Every object passes through the hub; who produces, who receives
Each row is one version group. Chips carry the module’s OCPI name and are coloured by direction; the arrow shows which directions are open between the hub and a party in that group. Clicking a chip jumps to its row.
OCPI 2.2.1
9 module · go to table ↓
CPO
charging network
ChargeBridge · hub
eMSP
driver app
OCPI 2.3.0
4 module · go to table ↓
Türkiye extension
1 module · go to table ↓
- CPO sends, eMSP receives through the hub
- eMSP sends, CPO receives through the hub
- Both ways: each side sends and receives
- Hub-originated: the hub informs both sides
No object flows without an accepted partner relationship; the arrow on the map is the protocol’s direction, not a permission.
Version group 01
OCPI 2.2.1
The core of roaming: credentials, locations, tariffs, sessions, CDRs, tokens and commands.
9 module · Last verified: 4 October 2026
| Module | CPO | eMSP | Summary and scope | Status | Evidence | Last verified |
|---|---|---|---|---|---|---|
| locations OCPI 2.2.1 | Sender | Receiver | Locations, EVSEs and connectors with live status. Full and partial (PATCH) updates; per-partner publish scope via sharing sets so a CPO decides which location each eMSP sees. Source: ocpi-adapter · routes/ocpi-221.routes.ts | Offered | 1/4 Present in source code Inspect evidenceOCPI 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 | 4 October 2026 |
| sessions OCPI 2.2.1 | Sender | Receiver | Charging sessions in progress, from start to end. Session objects with status transitions and charging periods; relayed only along accepted partner relationships. Source: ocpi-adapter · routes/ocpi-221.routes.ts | Offered | 1/4 Present in source code Inspect evidenceOCPI 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 | 4 October 2026 |
| cdrs OCPI 2.2.1 | Sender | Receiver | Charge detail records: the billable record of a session. Validation against tariff and session, idempotent intake, then entry into the settlement window. Türkiye-specific fields travel in the tr-cdr-additionals extension. Source: ocpi-adapter · routes/ocpi-221.routes.ts | Offered | 2/4 Real screen or document Inspect evidenceOCPI 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 | 4 October 2026 |
| tariffs OCPI 2.2.1 | Sender | Receiver | Tariff definitions with price components and restrictions. Energy, time, flat and parking components; per-partner tariff visibility follows the same sharing scope as locations. Source: ocpi-adapter · routes/ocpi-221.routes.ts | Offered | 1/4 Present in source code Inspect evidenceOCPI 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 | 4 October 2026 |
| tokens OCPI 2.2.1 | Receiver | Sender | Driver tokens (RFID, app) and real-time authorization. Token push and real-time authorize; stored token material is hashed and subject to the retention sweep. Source: ocpi-adapter · routes/ocpi-221.routes.ts | Offered | 1/4 Present in source code Inspect evidenceOCPI 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 | 4 October 2026 |
| commands OCPI 2.2.1 | Receiver | Sender | Remote start, stop, reserve and unlock, relayed through the hub. Command and asynchronous result routing with ownership and visibility checks: a command reaches a charger only if the eMSP is allowed to see it. Source: ocpi-adapter · routes/ocpi-221.routes.ts | Offered | 1/4 Present in source code Inspect evidenceOCPI 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 | 4 October 2026 |
| chargingprofiles OCPI 2.2.1 | Receiver | Sender | Smart-charging profiles set and read through the hub. Profile set, get and clear with asynchronous results; the hub relays, it does not compute charging schedules. Source: ocpi-adapter · routes/ocpi-221.routes.ts | Offered | 1/4 Present in source code Inspect evidenceOCPI 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 | 4 October 2026 |
| credentials OCPI 2.2.1 | Sender and receiver | Sender and receiver | Registration handshake and token lifecycle between a partner and the hub. Token A/B/C exchange, version negotiation and endpoint discovery are completed hub-side; inbound and outbound registration are both supported. A completed handshake does not by itself open data flow: an explicitly accepted partner relationship is required. Source: ocpi-adapter · routes/ocpi-221.routes.ts | Offered | 1/4 Present in source code Inspect evidenceOCPI 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 | 4 October 2026 |
| hubclientinfo OCPI 2.2.1 | Receiver | Receiver | The hub tells each partner which other parties are connected and in which role. Directory of connected parties with role and status; the public website publishes no party list. Source: ocpi-adapter · routes/ocpi-221.routes.ts | Offered | 1/4 Present in source code Inspect evidenceOCPI 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 | 4 October 2026 |
Version group 02
OCPI 2.3.0
A separate version endpoint; a translation layer sits between it and 2.2.1 partners.
4 module · Last verified: 4 October 2026
| Module | CPO | eMSP | Summary and scope | Status | Evidence | Last verified |
|---|---|---|---|---|---|---|
| parking OCPI 2.3.0 | Sender | Receiver | Parking-bay information attached to locations. Bay attributes and restrictions as defined in OCPI 2.3.0; follows location publish scope. Source: ocpi-adapter · routes/ocpi-230.routes.ts | Offered | 1/4 Present in source code Inspect evidenceOCPI 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 | 4 October 2026 |
| payment OCPI 2.3.0 | Sender | Receiver | Payment-session objects for ad-hoc (card) charging as defined in OCPI 2.3.0. The hub relays the protocol objects. It is not a payment institution and does not process cardholder data; money moves between the parties’ own payment providers. Source: ocpi-adapter · routes/ocpi-230.routes.ts | Offered | 1/4 Present in source code Inspect evidenceOCPI 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 | 4 October 2026 |
| bookings OCPI 2.3.0 | Receiver | Sender | Reservation of a charger for a time window, create and cancel. OCPI 2.3.0 booking objects routed in both directions along accepted relationships. Source: ocpi-adapter · routes/ocpi-230.routes.ts | Offered | 1/4 Present in source code Inspect evidenceOCPI 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 | 4 October 2026 |
| tokens (groups) OCPI 2.3.0 | Receiver | Sender | Grouping of tokens for fleet and shared-account scenarios. Group objects as defined in OCPI 2.3.0; authorization follows the group. Source: ocpi-adapter · routes/ocpi-230.routes.ts | Offered | 1/4 Present in source code Inspect evidenceOCPI 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 | 4 October 2026 |
Version group 03
Türkiye extension
The fields local reporting and tax rules need, carried with the CDR as an OCPI extension.
1 module · Last verified: 4 October 2026
| Module | CPO | eMSP | Summary and scope | Status | Evidence | Last verified |
|---|---|---|---|---|---|---|
| tr-cdr-additionals TR extension | Sender | Receiver | Türkiye profile: the CDR fields local regulation and tax rules need, carried as an OCPI extension. Utility rate in TRY/kWh, VAT breakdown and the identifiers both parties need for reporting; sent by the CPO alongside the CDR. The profile was authored by ZES as the OCPI-TR custom module specification; E-Gridium implements it and thanks ZES for opening it to the ecosystem. Source: ocpi-adapter · tr-cdr-additionals.controller.ts; docs/integration/TR_CDRADDITIONALS_PROFILE.md | Offered | 2/4 Real screen or document Inspect evidenceTü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 Türkiye profile: binding interpretation of tr-cdradditionals· Document Eight rules the hub applies where the specification leaves room: unit price semantics and precision, VAT handling, versioned corrections, idempotency responses, discovery via version details, eventual matching with a 24-hour compliance-gap report, serial-number reading, transport security. Open points are confirmed with the specification’s author before integration. Supports:The rule table on the Türkiye page. Does not show:Regulatory acceptance; the profile is a technical agreement between integrating parties. Source: OCPI-TR Custom Modules specification v1.0.0 (ZES, 19 January 2026) and the hub implementation profile docs/integration/TR_CDRADDITIONALS_PROFILE.md · Verified4 October 2026 | 4 October 2026 |
Not offered
What is not part of the service
Not part of the service; stated so nobody assumes it.
Negative claims are bound to evidence too: each card points at a record that says what is not installed in the source or what an endpoint returns.
- OICP bridge Not offered
Translation between OICP and OCPI is not offered.
A bridge exists in the codebase but is not installed in any environment. Partners who need OICP must connect to that network directly.
Last verified: 4 October 2026 · Source: docs/active/LAUNCH-DECISIONS-2026-08.md #8
1/4 Present in source codeInspect evidence
All evidence records →OICP bridge not installed· Source code review
The OICP-to-OCPI bridge service is marked installed:false in every environment and has no outbound HTTP client; the launch decision record keeps it out of scope.
Supports:The negative claim on the modules page: OICP translation is not offered.
Does not show:Any future availability.
Source: ChargeBridge hub source repository (private), reviewed on the date given · Verified4 October 2026
- webhooks Not offered
Event webhooks outside OCPI are not offered.
Partners receive events through the OCPI modules above; a separate webhook delivery channel is not part of the service.
Last verified: 4 October 2026 · Source: docs/active/LAUNCH-DECISIONS-2026-08.md #6
1/4 Present in source codeInspect evidence
All evidence records →Webhook endpoints return 501· Source code review
The seven webhook endpoints answer 501 Not Implemented and were removed from the public path list and the portal navigation by the launch decision record; the delivery chain is not wired.
Supports:The negative claim on the modules page: webhooks are not offered.
Does not show:Any future availability.
Source: ChargeBridge hub source repository (private), reviewed on the date given · Verified4 October 2026
For machines
The same list, the same fields, as JSON
Every row on this page comes from one data source, and the same source is read by the public API, the MCP server and llms.txt. The page and the machine answer never drift apart.
Developers and MCP →- REST
- GET /api/public/v1/modules
- MCP
- list_modules
- Row anchor
- /en/ocpi-modules#<module-id>
How it proceeds
- 01Apply with your role and versions endpoint
- 02Sign the participation agreement and DPA
- 03Handshake in the sandbox, then accept relationships