Setup of the OICP 2.3 adapter for CPOs from scratch
Our client is a charge point operator in the German market, running their own internal platform for managing charging infrastructure and the commercial side of the business.
Their priority was reach. To make their stations available to drivers outside their own customer base, they needed to connect to Hubject’s HBS platform over OICP 2.3, a protocol their system did not speak. Shortly afterwards the same question returned for direct partner connections over OCPI, which meant the integration work had to be planned with both standards in view rather than solved twice.
In a nutshell
An OICP 2.3 adapter built from scratch, connecting the client’s internal system with Hubject’s HBS platform and covering the full data exchange and mapping between them. In parallel the client added our OCPI 2.2 gateway to their stack, with the ability to modify the code, which opened the door to partner integrations over OCPI within weeks rather than months.
Challenges
We ran the project as two parallel streams. The first was the technical build: an OICP 2.3 adapter for a CPO, created from scratch, including the implementation of the complete OICP data model. The second, led by our domain expert, mapped the similarities and differences between OCPI 2.2 and OICP 2.3. That comparison work existed for a practical reason – it let us settle the data API contract between the client’s internal system and both adapters far earlier than a sequential approach would allow.
The hardest part proved to be end-to-end integration with Hubject’s QA environment. The official documentation turned out to be inconsistent in several areas, and those inconsistencies only surface once real data is moving in both directions. Because we had started integration testing early, each finding could be raised with Hubject’s support team and resolved while the cost of change was still low.
Our approach
Rather than treating documentation as ground truth, we treated the live QA platform as the reference and tested against it from the first weeks of the project. Constant contact with Hubject’s support team turned potential blockers into short conversations. The adapter was then mapped and integrated with the client’s internal system over an HTTP API, giving a clean end-to-end path from their platform, through the adapter, to the roaming hub.
When the client decided to also connect with external partners over OCPI, rebuilding that layer from scratch would have repeated months of work. Instead we brought in our OCPI 2.2 gateway as a ready component with code access, and within a few weeks the client completed the OCPI handshake and began exchanging charging location data with partners.
Two roaming paths from one integration effort
The result is a client able to reach the market through both protocol families: OICP into the Hubject ecosystem, and OCPI directly to partners. Because the data contract was designed once, with both standards in view, the two paths sit on the same foundation instead of becoming two disconnected integrations to maintain.
Outcomes
An advanced migration to our CPMS system backed by custom development and ongoing maintenance. Migration involved 9000 charging points. A particularly complex aspect was ensuring the integration of the current EMP system, including mobile app users and the OCPI partners already connected.
Comprehensive custom CPMS system and effective migration, seamlessly integrating with GreenWay’s existing digital ecosystem to future-proof their high-volume EV charging network across the CEE region.
Entire digital ecosystem for EV charging including Charge Point Operator Platform, eMobility Service Provider application and customly developed software tailored to IECharge®’s unique needs.
