| 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 codeInspect 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 |
| locations | OCPI 2.2.1 | →Sender | Locations, EVSEs and connectors with live status. | Offered | 1/4 Present in source codeInspect 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 |
| tariffs | OCPI 2.2.1 | →Sender | Tariff definitions with price components and restrictions. | Offered | 1/4 Present in source codeInspect 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 |
| sessions | OCPI 2.2.1 | →Sender | Charging sessions in progress, from start to end. | Offered | 1/4 Present in source codeInspect 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 |
| cdrs | OCPI 2.2.1 | →Sender | Charge detail records: the billable record of a session. | Offered | 2/4 Real screen or documentInspect 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 |
| tokens | OCPI 2.2.1 | ←Receiver | Driver tokens (RFID, app) and real-time authorization. | Offered | 1/4 Present in source codeInspect 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 |
| commands | OCPI 2.2.1 | ←Receiver | Remote start, stop, reserve and unlock, relayed through the hub. | Offered | 1/4 Present in source codeInspect 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 |
| chargingprofiles | OCPI 2.2.1 | ←Receiver | Smart-charging profiles set and read through the hub. | Offered | 1/4 Present in source codeInspect 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 |
| tr-cdr-additionals | TR extension | →Sender | Türkiye profile: the CDR fields local regulation and tax rules need, carried as an OCPI extension. | Offered | 2/4 Real screen or documentInspect 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 |
| parking | OCPI 2.3.0 | →Sender | Parking-bay information attached to locations. | Offered | 1/4 Present in source codeInspect 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 |
