Skip to content
e-Gridium
Menu

Hub

Partners

Apply to connect Türkçe

Trust

What stands behind each claim?

Rule: no record without an inspectable artefact or a dated review; every record says what it supports and what it does not show.

evidence records
17
modules linked to a record
16 / 16
records overdue for review
0
catalogue version
4 October 2026

Being linked to a record does not mean the whole claim is verified; the evidence level is derived from the record kind and is not product availability. Modules that are not offered are linked to a record too: a negative claim needs evidence as well.

One record set

The module table, role pages, trust page, public API, llms.txt and MCP are generated from this one record set; if evidence is not updated here, it looks outdated everywhere.

  • 4/4 Verified in production or field
  • 3/4 Verified by automated tests
  • 2/4 Real screen or document
  • 1/4 Present in source code
Source code review 1/4 Present in source code

OCPI 2.2.1 route table

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

Source code review 1/4 Present in source code

OCPI 2.3.0 route table

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

Source code review 1/4 Present in source code

Türkiye CDR extension (tr-cdr-additionals)

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)

Source code review 1/4 Present in source code

Settlement window state machine

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

Source code review 1/4 Present in source code

Hash-chained settlement ledger

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

Source code review 1/4 Present in source code

Fail-closed partner relationships

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

Source code review 1/4 Present in source code

Retention sweep for token material

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

Test suite 3/4 Verified by automated tests

Automated 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)

Document 2/4 Real screen or document

OpenAPI specifications

Machine-readable API descriptions for the OCPI adapter, the clearing platform and the identity service, published on the developers page.

Supports
The endpoint surface a partner integrates against.
Does not show
Access: endpoints require partner credentials issued during onboarding.

Source: OpenAPI documents generated from the hub services

Open source ↗
Document 2/4 Real screen or document

Compliance programme status

ISO/IEC 27001:2022 in progress (gap assessment, target end of 2026), SOC 2 in planning, PCI DSS SAQ-A scoped as a self-assessment; the matrix tracks each control’s status and owner.

Supports
That the programmes exist and their stated status on the trust page.
Does not show
Any certification or attestation: none has been issued for E-Gridium.

Source: Hub repository, docs/compliance/compliance-status.json and COMPLIANCE-MATRIX.md

Source code review 1/4 Present in source code

OICP bridge not installed

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

Source code review 1/4 Present in source code

Webhook endpoints return 501

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

Source code review 1/4 Present in source code

Engineering footprint of the hub

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

Document 2/4 Real screen or document

Settlement architecture: agreements, windows, statements, obligations

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)

Document 2/4 Real screen or document

Türkiye profile: binding interpretation of tr-cdradditionals

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

Source code review 1/4 Present in source code

Hub portal views per role

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

Source code review 1/4 Present in source code

Partner sandbox

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

Machine access · The same records are served as JSON and over MCP.

GET /api/public/v1/evidence MCP →

How it proceeds

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

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

Apply to connect Onboarding and sandbox →