See the third lesson of our comprehensive e-mobility training on OICP!

Having a chance to work with well-established startups from the e-mobility sector, Bartek gained invaluable knowledge on the industry requirements. On his path, he was given the opportunity to work on numerous EMSP applications and CPO platforms. Bartek is also our Head of Delivery.

Bartłomiej Łazarczyk

 is happy to introduce you to the Open Standards course led by our e-mobility expert - Bartlomiej. Throughout the following lessons, we will uncover the technicalities and functionalities of the OICP - a protocol developed by 

 - as well as business aspects for e-Mobility Service Providers and Charge Point Operators.

Such a knowledge-pack should serve everyone operating in the e-mobility industry as it unfolds the most crucial aspects of navigating through Open Standards utilization and many more!


Subscribe to our YouTube channel to make sure you don't miss out on the upcoming training entries.

Open InterCharge Protocol Training - Lesson 3

In this module, let's cover some basic technical details characteristic for OICP.

Beginning with OICP version 2.2, every communication must be based on HTTP protocol and use JSON data format in messages. In the past, it was also possible to use SOAP protocol but now it's deprecated and cannot be used anymore. Every service in OICP is synchronous, therefore for each request there must be a response. In most of the services, the response format is an acknowledgement message. When it comes to the character encoding in OICP, there must be in UTF-8. Worth mentioning is the fact that the Hubject platform is highly available. All the details regarding the SLA are individually specified in your partner contracts.

Speaking of data, Hubject aims for high quality data management to enable all partners further scaling. In order to avoid data-related issues, Hubject provides point-of-interest data quality guidelines. Each guideline is a list of property names together with type, description, example and information whether this data is mandatory or not. The other reason for that step is to guarantee a good charging experience for customers and a unique selling point. Each partner is obliged to fill in a point-of-interest data check form and mark if they are able to meet the requirements for specific property. Building form should be sent to your support onboarding team before end-to-end test.

As I've just said, a response message should be a result of any kind of operation in services. In this response message, you must also include information about the status of a given operation. OICP has its own standardized status code and description format. State is called message property - a carrier of that information. The general status code is 000. Below, you can find an example: how it looks like in practice and what is the typical status code response.

Hubject distinguishes between four different types of status codes. The first type is internal system code; here we can include information that an error is about the Hubject system, Hubject database, data transaction, unauthorized access, inconsistent EVcoID, inconsistent EVseID, more general system or data errors.

The next types of status codes are the authentication ones. Here, we can specify more details regarding authentication related errors i.e. we may specify that we had invalid credentials for QR code, that we had invalid UID or cards not readable for RFID, that we have invalid EVcoID for PLC, that we had no positive authentication response, that we have received timeout error on QR code authentication, that we had invalid underlying EVcoID, invalid certificate or timeout error on PLC or that EVcoID was blocked.

Then, we have session related codes. What's more important, those are not the codes related with the charging session itself, but with the session mechanism. So, we may specify that there is no valid contract, that partner is not found, that partner did not respond, that the service is unavailable or that the session is invalid.

Finally, we have EVSE related codes which can specify more details about problems with charging station i.e. we can specify that communication with EVSE has failed, that there is no electric vehicle connected to EVSE , that EVSE is already reserved, that EVSE is already in use or that we have received wrong token, that we don't know EVSE ID and it is unknown, that EVSE ID is not Hubject-compatible or that EVSE is out of a service.

Some services, especially authorization service, require a session mechanism in order to correlate a series of individual operations. The typical scenario is i.e. charging start and stop, as well as pushing CDR correlated with the already finished charging session. If that happens, then session ID must be returned in a response for every initial request i.e. eRoamingAuthorizeStart. Session ID must be provided in each subsequence request. It's good to know that the session ID created by Hubject is in GUID format.

Hubject also offers a possibility to use your own session mechanism by adding two additional properties to each initial request: CPO partner session ID or EMP partner session ID. If the value in one of those properties is provided, then it will be used as a session ID after the initial request. The same value beside the session ID will be also returned as a CPO partner session ID or EMP partner session ID in order to make processing a little bit easier.

In OICP, the message format can be the same for both types of roles: CPO or EMP. Because of that, Hubject needed to create another mechanism in order to differentiate service operations between those two rows. You, as a partner, need to provide in each request either provider ID if you're an EMP or operator ID if you are a CPO. Those two identifiers are unique within the whole Hubject platform and they are assigned to you as a partner during the onboarding process. You, as a partner, may also have both rows CPO and EMP; in this case you need to provide only one value either provider ID or operator ID in each request. Operator ID and provider ID have similar format but with the small differences which we will see in examples later. In general, they are created according to the ISO15118 specification. When it comes to the date and time, it's pretty simple; it needs to be delivered in a given ISO format. It's good to know that Hubject will store those values in their databases in their original form - there will be no conversion to UTC, timestamp or any other form. Below, you can find an example of what it looks like and what the format is.

One of the most important things to remember about OICP protocol is that the data push request for the same service operation needs to be sent sequentially. For example: if you push EVSE data in a few requests, then please make sure that they are being executed one by one after a response from a server is received. The reason for that is because Hubject can process those requests in parallel, therefore sending many requests at the same time may change the expected result or even unintentionally override the data set.

Pagination was introduced in some services in the latest OCIP version. Nothing extraordinary, but it's good to know what the response looks like with properties; content which is a list of elements: number, size, total elements, number of elements, first, last and total pages. When it comes to the query itself, it's also pretty straightforward, you need to provide page and size.

Security aspect of the OICP protocol is also very convenient. Hubject will compare if the provider ID or operator ID is compliant with your SSL client certificate in every request. That should prevent the situation when some partner will perform an operation in the name of the other partner just by providing the correct ID. If there will be a mismatch, then the 017 status code should be returned with an unauthorized access message. Please remember also that Hubject will validate if the IP is on the white list, so your server must have a static IP.

Details of certificate signing request generation will be delivered to you during the pre-contract phase, but in general this process is quite simple. But first, you need to generate private and public key in order to encrypt and decrypt some messages. Then, you need to generate CSR with PKSCS10 standard. After that, you need to send it to Hubject via email and also send the passwords or encrypted files in some other way. Onboarding manager will verify if everything went correctly and they will sign those certificates. Also, in the QA phase, you will receive signed partner certificates together with CA certificates to convert them and finally you can access web services with client authentication.

Checklist - Core CPO platform requirements

See our response to the dilemma of what suits you best in terms of eMobility software products

After founding Solidstudio, Pawel was an originator in terms of pursuing expertise in eMobility. With the build-up of a solid knowledge-base on industry’s needs & wants, he now keeps a close eye on products’ development. He’s also hugely responsible for the business’ side and designs the business models for our products.

Paweł Małkowiak

There are many classifications on which one may categorize software products and services. From a whole plethora of different aspects, one that seems to be worthy of consideration in the e-Mobility software world is certainly the one taking on how a product is acquired.

Charge Point Operators and e-Mobility Service Providers

 will eventually face the task of choosing appropriate software to run their charging networks (unless they have their own dev team ready to build it from scratch - a fairly rare occurrence).

With a careful selection of the most suitable IT solution, one of the core questions to answer is whether to come down in favor of an off-the-shelf product or to get it customarily developed.

Custom vs ready-made: general breakthrough

Generally speaking, both have a multitude of advantages, much like some drawbacks. It’s crucial to understand what both of the options bring to the table.

, the first thing that comes into play for many companies may be how long it will take before their investment can yield a return and generate profits. As an old saying goes ‘time is money’ and thus, those who care about rather fast implementation and launch, would certainly lean towards ready-made solutions.

Being already on the market and broadly-available, makes the aforementioned option a cheaper one as it does not require hiring a team of devs and putting them to work for what might be a few months. Those who are on tight budgets or simply not willing to spend too much, will certainly look favorably to getting ready products.

Finally, there’s less risk of failure. Off-the-shelf products usually had their fair share of being tested inside out by many. This allowed their developers and manufacturers to implement necessary ameliorations and adjustments.

However it’s not all fun and games… There are some major obstacles in terms of read-made solutions. Missing crucial features is one of them. Broadly-available software products tend to be created in such a way as to suit the basic requirements of many different, potential customers. Unfortunately, there's no one-size fits all solution when it comes to IT. With such an approach, some of the more specific features can be omitted, leaving some gaps in fulfilling all the needs of a certain company - this is where custom development still comes in place even with off-the-shelf software.

, one gains the assurance of getting all the necessary functionalities. There is also guarantee of no need in paying for features which are of no use. Custom development is the best solution if one needs only one or two particular features of an enterprise package, but there are no corresponding ready-made products on the market.

It also allows one to choose the best programming language and be able to work with new technologies while, in some cases, ready-made software is limited to a pre-set list of technologies.

With custom development the product can be adjusted to meet all the latest requirements and security standards which sometimes aren't included in ready-made software products. In addition, some old versions of ready-made software may lose market leadership or be left without support from software vendors.

There isn’t one definite answer here. Again, it all boils down to a well-thought-out choosing of what suits particular needs best. The more CPOs and EMPs are out there, the more different requirements and desires can arise.

Having said that, it must be underlined that eMobility operates as a part of a bigger ecosystem and stays interconnected with other branches, which may lead to eventual tie-ins. For example: the possibility to charge an EV can become an add-on function for a smart-home app, CPO platform may require rearranging tariffs management system or invoicing flow, etc.

The industry is known to evolve quickly. Rapid pace reinforces building innovation on top of 'must-have' functionalities. With Open Standards regularly upgrading to new versions, incoming CPOs and EMPs integrating with charging networks or ever-growing EVSE, one must stay on top of the software game in order to stay afloat in the business. Here’s where custom development may significantly help - but that doesn’t mean it’s the only good option out there.

Once again, it’s all in the careful choosing.

Custom vs off-the-shelf? Solidstudio’s bold response - the best of both worlds.

After years of gaining expertise of developing custom eMobility software, the decision of building our 

 came in rather organically. Knowing all the industry nuances and having a chance to talk to numerous EMPs and CPOs, including the small ones and the biggest players in the field, we got a good grasp on what’s really going on in the EV business world.

This is where the idea of developing customizable product backbones.

With some great efforts, our eMobility experts have managed to deliver a 

 (that comes with supporting web application) and 

, both fully customizable to suit specific needs. They’re designed in the form of a solid software backbone, and thus can pose as a product core on which every client can then build (with our continuous support) a product that matches their individual requirements.

Such a solution allows our customers to easily navigate through their needs and wants, depending on what is necessary. 

Whether they’re looking for a complete app, a ready app that still needs to be adjusted with specific functionalities, or a custom development from scratch, we’re well positioned to deliver whatever is needed in a form that suits the clients’ best interests.

 The broad range of amenities has been extended even to the settlement - as the products can be sold either on proprietary licensing (one-time fee) or as a flexible SaaS plan.

With hands-on experience, eMobility dev experts, many successfully finished projects and constantly staying up-to-date with the latest news, we are ready to take on any eMobility-related challenge and guide our clients through the best solutions, even when they’re not entirely sure what would work best for them.

See our response to the dilemma of whether to choose an off-the-shelf software or get it customarily developed

Custom vs off-the-shelf software products? Our response to the dilemma

Open standards can be a game changer for both eMSP's and CPO's. Here is why.

Being an eMobility leader in various projects across multiple startups, Piotr was responsible for OCPI and OCPP integration as well as EMP and CPO platforms development. With extensive expertise in the open standards field and eMobility tech solutions, he is leading teams of experienced developers and contributing with invaluable knowledge and experience.

Piotr Majcher

The initial stages of technologies lead to various types of solutions addressing the same problem. Each company develops a different approach. At the beginning of the XXth century, when commercial electricity had come to the mainstream, multiple energy producers offered power supply with miscellaneous frequencies and voltages. As time passed, governments began to impose certain standards on suppliers. This standard-setting led to the joint effort to create the first power grid.

From the first power plant to the moment when all energy providers linked to the same network, decades passed. This was only possible because they took a mutual direction.

 - literally and figuratively. With global warming, exhaustion of solid fuel resources, and lifestyle changes, companies face the challenge of how to provide accessible new charging forms of green power.

Now, as the e-mobility era is here, we are on the same page, like we were at the very beginning of the XXth century. We already have plenty of providers: eMobility Service Providers (eMSP) and Charge Point Operators (CPO) - two substantial sides of the e-Mobility world. One of the main challenges ahead of this market is to deliver the best user experience, at possible minimum resources use. As usual, user experience is a matter of well-designed apps, customer support, and simplicity itself. But there is an additional fact. End-users need to be able to charge cars at any charging station without being concerned about accessibility. The issue is - having the contract signed with the Charge Point Operators recharging point service. How to achieve this? Partners must take the same course, and this is where the standards start to play a major role. There are two possibilities: Open Charge Point Interfaces or Open Intercharge Protocols. What are the benefits?

The main goal of the Open Charge Point Interface (OCPI) is to allow electric vehicle drivers to charge their cars at any station. OCPI defines a set of modules that cover most cases the driver may need. There are two technical modules that are used to establish connectivity between two platforms using OCPI: Credentials module and Versions module. Other modules are strongly related to real-life use cases. These would be:

Locations - module responsible for sharing information about the Charge Points, like address, geolocation, real-time data about the current status, electrical parameters.

Sessions & Commands - module allows the end-user to start the charging session and be informed about the current status of the charging session.

OCPI is an open standard, and what may be very important for the adopters - it’s very flexible. For instance, CPOs (Charge Point Operators) may implement only the Locations module (apart from two technical mandatory modules) when only sharing Point Of Interest data. With no necessary exposing the eRoaming functionality. But the ultimate goal for many CPOs is to allow end-users to charge their car. In that case, many more modules need to be implemented (Sessions, Commands, CDRs). Some others are optional, even for the eRoaming (Tokens, Tariffs), and that depends on the agreement between certain allies. It’s in terms of how financial flow and security is modeled.

The biggest advantage of having OCPI implemented is that it’s almost a one-time investment. The initial effort is significant, as it might be challenging to transfer internal models and processes to the OCPI. But once it’s done for a partner, it opens the company for quick and cost-effective integration with a lot of other associates.

A bit different concept is proposed by the Berlin-based innovative company - Hubject. Hubject developed its own API (OICP) covering almost the same cases as OCPI. There is one extra. Hubject also acts as a hub. It connects CPOs and eMSPs. Once a company is connected to the Hubject platform, it becomes open for integration with any other comrade being already assigned. That’s a huge advantage because the integration is done once, with one platform, and of course it becomes profitable when it comes to an alliance with multiple partners.

Yet another advantage of the Open Intercharge Protocol is that it’s quite easy to implement. Like with most protocols, the main challenge is to synchronize our internal models with the standard one. What is comforting with OICP - there is not too much to implement. It depends on the level of integration we want to achieve, but it’s enough to implement about 5 HTTP calls to expose eRoaming through the Hubject platform.

Having in mind multiple historical examples, it may be difficult to be a part of a developed market without following widely adopted standards. Initially, it may need some additional effort. But when the standard is implemented, our platform becomes open for the whole market 

. Without it, we would need to spend weeks or months doing the integration with each partner separately.

OICP and OCPI protocols - open standards for CPOs and eMSPs

Download our comprehensive PDF and learn about the pricing structures in e-mobility

Although it would seem rather straightforward, the pricing system within the EV charging environment extends further than just to the payments made by electric vehicles right after they charge their car.

Being such an interconnected network of mutual dependencies between numerous involved parties, e-mobility charging services require various levels of settlements.


It must be noted that it takes a few units to build up and manage a charging network. From 

, which manufacture the hardware side of required components (connectors, chargers, cables, etc), through 

, which are responsible for the backend management, all the way to 

, which determine the final user (here: EV driver) experience, there is a whole network of reliabilities.

Put simply and briefly, CPO’s are to establish billing connections with both EVSE and eMSP’s, in order to put the entire charging formation in place, while ensuring all parties receive transparent information and clear instructions.

To facilitate it, there are multiple types of pricings and contracts, some of which allow for complex, dynamic price models. Such undertaking is required so that eMSP’s can shape their end-users pricing often based on certain conditions, leaving the rates flexible.


Interoperability - the core of proper functioning

It should go without saying, that managing a pool of charging stations - oftentimes distributed across entire countries/regions - is not an easy task to handle and can only be achieved via advanced levels of interoperability and clear, unified procedures.

Open Standards are the chief example of how this can be achieved and maintained. Through the utilization of API’s like OICP the flow of information can be sustained in a transparent manner. This allows for a seamless communication and can facilitate the management of a vast majority of proceedings remotely, which comes in handy while developing a state-wide network, especially when there are numerous parties involved.


Knowing the behind-the-scenes nuances and arrangements, we prepared a comprehensive paper portraying the pricing structure within the e-mobility industry. Those who are willing to learn more about tariffs within charging services, should definitely find it useful.

Download our free paper and broaden your horizons with some great knowledge!

Open InterCharge Protocole Training. Lesson 3

17 FEBRUARY 2022 • 10 MIN READ