If your charging stations don't support RFID tokens, the easiest way to start a charging session is to use remote authorization. Having worked with dozens of EV charging networks, I'd like to share with you how to integrate with the Hubject eRoaming backend using remote authorization.
But makes the easiest charge point operator API, allowing for starting a charging session with remote authorization? I would say there are three factors:
- Expose information about our charge points to let the EV driver find them
- Allow the options: start and stop charging
- Send the charging session data (Charge Detail Records, or CDR)
What I really like about Hubject's API is that these high-level features are mapped one-to-one to their API operations. For this e-mobility solution, five operations have to be implemented to enable eRoaming through Hubject's platform into our system.
Unlike the OCPI protocol, there is no complicated handshake. On the API level, there are no security operations. It's the SSL Client Authentication that takes care of it, so there is no need to obtain tokens, etc. In fact, there are no “technical” endpoints that you need to implement, only those related to the business processes.
Let's start by exposing our charge points to the end-users (EV drivers).
Quick review: What is Hubject?
Hubject is the world’s leading e-roaming platform, connecting over 2,000 partners across the EV ecosystem: from charge point operators to eMobility providers. Its core technology, the OICP protocol, allows seamless integration and interoperability between EV charging networks.
This roaming platform acts as a digital bridge that enables EV drivers to start, stop, and pay for charging sessions across various networks, so they don't need multiple apps or subscriptions. This unified access significantly improves the charging experience across borders and providers, turning fragmented infrastructure into a connected charging network.
By integrating with the Hubject eRoaming backend, CPOs and eMSPs get access to a growing global EV ecosystem, ensure charging station visibility, and support remote authorization, real-time data exchange, and compliant charge detail record (CDR) submissions.
Sharing charge point data
In order to let end-users find our EV charging stations on Hubject's map (or on the maps of any eMobility service provider integrated with Hubject), you have to share both static and dynamic data of your charging network. Open Intercharge Protocol (OICP) supports this process with two operations:
- eRoamingEvseData
- eRoamingEvseStatus
You should use them for real-time changes and batch updates. If your EV charging network data (static or dynamic) changes, you should synchronize it with Hubject's B2B Service Platform (HBS platform) in real-time. Additionally, charge point operators should send daily updates of all existing charge points, including static and dynamic data.
Deleting EVSE data
Deleting your charging station data may be a complicated operation. Usually, you don't want to delete a charge point completely. You may need to store information about the deleted charge points for some reports, historical statistics, or investigations. That's the "delete" operation, which isn't explicitly modeled.
You can do it by setting the charge point status to “out of order” or ”valid to” date for the charge point. Each charge point operator has some logic based on which you can tell if the charge point should be visible on the map or not.
This is where the OICP-based roaming batch update comes up. Instead of deleting the charge point that is out of order, you can run a full load, and the invisible charge point will be removed from Hubject's system. With such a solution, you bring some level of eventual consistency. Of course, the straightforward delete operation is also supported, so if your system has the ‘delete' operation modeled, you can simply use it.
Starting and stopping charging sessions
Once you share your charging stations with the EV drivers, you should allow them to start and stop the sessions. There are two operations responsible for that in the OICP protocol:
- eRoamingAuthorizeRemoteStart
- eRoamingAuthorizeRemoteStop
Charge detail records: What you must send
When an electric vehicle starts charging, you need to collect specific information:
- Which charge point does the EV driver want to use
- Information about the eMobility provider within the eRoaming ecosystem, as many service providers can use your platform (good for reporting)
- EV driver identification
- Charging session identifier to know which session has to be stopped when our charging infrastructure backend receives the command "eRoamingAuthorizeRemoteStop"
And that's exactly what your CPO platform receives each time the charging process starts.
How charge point operators identify the end-user
It basically depends on the "start" method.
For the remote start, it's called EvcoId, and it's a contract identifier between the eMobility service provider and the end-user charging the car. You have to store this value in the system because it has to be sent to the HBS together with a completed charging detail record.
It works similarly for the "SessionId", but as a more common concept, there is a chance that your backend will already have an idea of the session with some identifier, and it'll also be assigned to the charging data record.
If not, then you have to enrich your CDR with two values before sending it to HBS:
- EvcoId
- SessionId
That leads us to the last API call you have to implement.
eRoaming ecosystem: sharing charge data records
You can do it with a single API call:
- eRoamingChargeDetailRecord
Most of the fields you send to Hubject are probably stored in the CPO platform. There are charging start and end, meter value start and end, and more. Apart from that, there are two parameters, already mentioned in the previous paragraph (SessionId and EvcoId) that our CDR has to be enriched with.
Improve the charging experience with e-roaming
Visibility is important, but integrating with Hubject is also about functionality. Remote start, stop, CDR exchange, EVSE status sync, all of it works through a clean, SSL-authenticated connection with five core API operations.
Once connected, your platform becomes part of a much larger network of CPOs and eMSPs. Drivers see your stations. Sessions start reliably. Data flows automatically.
The integration isn’t complex, but it has to be done right.
If you're building a backend that supports real-world charging at scale, connecting to the eRoaming ecosystem through Hubject is a critical step. And if you want it done fast and right, Solidstudio can help, just contact us.