OCPI vs OICP vs OCHP: EV Charging Roaming Protocols Compared

OCPI, OICP, and OCHP are the three main protocols for EV charging roaming — enabling drivers to charge on networks they don't subscribe to. OCPI (Open Charge Point Interface) is the most widely adopted open protocol, governed by the EVRoaming Foundation. OICP (Open InterCharge Protocol) is Hubject's proprietary protocol, tightly coupled to their eRoaming platform. OCHP (Open Clearing House Protocol) is an older open protocol, originally developed for e-clearing.net, now largely superseded by OCPI in most new implementations.

Choosing the right roaming protocol — or combination of protocols — has real consequences for your integration timeline, partner reach, and long-term flexibility. This guide breaks down the technical and strategic differences so you can make an informed decision.

If you need partner-readiness validation before live onboarding, start with GIREVE OCPI testing or Hubject OICP testing.

Quick Comparison Table

OCPI: The Open Standard

Overview

OCPI is developed and maintained by the EVRoaming Foundation, a Dutch non-profit backed by major European CPOs and eMSPs. The specification is open-source, hosted on GitHub, and anyone can implement it without licensing fees or partnership agreements.

OCPI uses a straightforward REST API with JSON payloads. If you've built any modern web API, the architecture will be immediately familiar. Each party hosts its own OCPI endpoints, and data exchange happens through standard HTTP methods.

Key Technical Characteristics

Modular architecture: OCPI is divided into independent modules — Locations, Sessions, CDRs, Tariffs, Tokens, Commands, and Hub Client Info. You implement only the modules you need. A CPO publishing charger locations doesn't need to implement the Commands module if they don't support remote start.

Peer-to-peer or hub-based: OCPI supports both direct bilateral connections between parties and connections through roaming hubs. In practice, most companies connect through a hub like GIREVE to avoid maintaining dozens of individual connections.

Pull and Push: Data can be pulled on demand or pushed in real-time. Locations data, for example, can be pulled in bulk during initial sync and then pushed incrementally as availability changes.

Versions in the Wild

• OCPI 2.1.1 remains the most widely deployed version. It covers all core roaming functionality and is supported by every major hub.
• OCPI 2.2.1 adds hub-specific features, charging preferences, improved tariff structures, and better error handling. Most new implementations target 2.2.1.
• OCPI 3.0 is under development and will introduce breaking changes, including a redesigned module structure and improved real-time capabilities.

For a deeper dive into OCPI's architecture and modules, see our complete guide: What is OCPI?

Strengths

• Fully open specification with no vendor lock-in
• Largest and most active developer community
• Clean REST/JSON architecture that integrates easily with modern tech stacks
• Supported by all major roaming hubs (GIREVE, Hubject, e-clearing.net)
• Active development with a clear roadmap

Limitations

• Real-time capabilities in 2.1.1 are limited (improved in 2.2.1)
• No built-in PKI infrastructure for Plug&Charge (relies on external certificate management)
• The specification allows flexibility that can lead to inconsistent implementations between partners

OICP: Hubject's Protocol

Overview

OICP is the protocol behind Hubject's intercharge network, one of the largest EV roaming platforms globally. Unlike OCPI, OICP is proprietary — you implement it as part of a commercial relationship with Hubject. The specification is not publicly available; you receive access after signing a partnership agreement.

Hubject operates as a centralized B2B platform. All roaming data flows through Hubject's infrastructure. This means you don't establish direct connections with other CPOs or eMSPs — Hubject mediates every interaction.

Key Technical Characteristics

Hub-centric architecture: OICP is designed exclusively for hub-based communication. There is no peer-to-peer mode. Every authorization request, session record, and CDR passes through Hubject's platform.

Evolved from SOAP to REST: Earlier versions of OICP used SOAP/XML, which added significant implementation complexity. Recent versions (2.3+) have migrated to REST/JSON, bringing the developer experience closer to OCPI.

Integrated Plug&Charge: Hubject operates a Public Key Infrastructure (PKI) for ISO 15118 Plug&Charge. If Plug&Charge is a priority for your network, Hubject offers one of the most mature certificate management solutions in the industry. This is a genuine differentiator — managing a PKI independently is complex and expensive.

Built-in business services: Beyond protocol-level data exchange, Hubject's platform includes business intelligence dashboards, partner discovery, and contract management. The protocol and the platform are deliberately intertwined.

Strengths

• Mature Plug&Charge / ISO 15118 PKI infrastructure
• Strong market presence in Germany, Austria, and expanding in Asia-Pacific
• Integrated business tools beyond raw data exchange
• Large connected network with 400+ B2B partners

Limitations

• Proprietary specification — no public access, no community contributions
• Vendor lock-in: your roaming capability is tied to Hubject's platform and pricing
• All data routes through Hubject's infrastructure (potential single point of failure, data sovereignty considerations)
• Commercial fees for every roaming transaction
• Less flexibility for custom integrations or direct bilateral agreements

OCHP: The Legacy Protocol

Overview

OCHP was one of the earliest attempts at standardizing EV charging roaming. Developed for the e-clearing.net platform — a joint initiative by smartlab, ElaadNL, and other early European players — OCHP aimed to solve the same interoperability problem that OCPI and OICP address today.

Key Technical Characteristics

SOAP-based: OCHP uses SOAP with XML payloads. This was standard when the protocol was designed, but it means significantly more implementation overhead compared to REST/JSON approaches. WSDL definitions, XML schemas, and SOAP envelope handling add friction for development teams accustomed to modern API patterns.

Clearing house model: OCHP was built specifically around the clearing house concept — a central party that handles authorization, session data, and financial settlement between CPOs and eMSPs. The protocol assumes this centralized topology.

Limited module scope: OCHP covers the basics — charger data exchange (known as "charge point info"), authorization, and charge detail records. It lacks the richer module set found in OCPI (tariffs, commands, real-time sessions) and the platform services bundled with OICP.

Current Status

OCHP adoption has been declining steadily. Most organizations that originally implemented OCHP have either migrated to OCPI or added OCPI as a parallel interface. The e-clearing.net platform itself now supports OCPI alongside OCHP.

New implementations of OCHP are rare. Unless you are integrating with a legacy partner that exclusively supports OCHP, there is little reason to implement it today.

Strengths

• Open specification
• Proven in production for over a decade
• Still supported by e-clearing.net

Limitations

• SOAP/XML adds significant development and maintenance overhead
• Small and shrinking community
• No Plug&Charge support
• No smart charging features
• Limited real-time session capabilities
• Declining adoption means fewer potential roaming partners

Which Protocol Should You Choose?

The right choice depends on your specific situation. Here is a decision framework based on the factors that matter most.

Geography

If your charging network operates primarily in Germany and Austria, OICP gives you immediate access to the densest roaming network in that region. Hubject's market share in DACH countries is substantial.

If you operate anywhere else in Europe, OCPI is the default choice. GIREVE, the largest European hub, uses OCPI as its primary protocol, and the majority of European CPOs and eMSPs have OCPI implementations.

If you are expanding into Asia-Pacific, both OCPI and OICP have growing presence. Hubject has been particularly active in South Korea and Japan. OCPI adoption is growing in India and Southeast Asia.

For North America, the roaming ecosystem is less mature, but OCPI is emerging as the preferred protocol as the market develops.

Hub Preference

Your hub choice often dictates your protocol:

• GIREVE primarily uses OCPI. Connecting to GIREVE means implementing OCPI.
• Hubject primarily uses OICP. Connecting to Hubject means implementing OICP (though they also accept OCPI).
• e-clearing.net supports both OCHP and OCPI. New connections should use OCPI.

See our GIREVE Hub Integration Guide for details on connecting to the largest European hub.

Technical Preference

If your team values open specifications, REST APIs, and community-driven development, OCPI is the natural fit. The spec is on GitHub. You can read it, file issues, and contribute.

If your team values an integrated platform with managed services and is comfortable with a commercial vendor relationship, OICP through Hubject provides a more turnkey experience.

Plug&Charge Requirements

If ISO 15118 Plug&Charge is a hard requirement today, Hubject's PKI infrastructure gives you a head start. While OCPI 2.2.1 supports Plug&Charge data exchange, it doesn't provide the certificate management infrastructure — you would need to source that separately or build your own.

Cost Considerations

OCPI itself is free to implement. Your costs are integration development time and any hub fees (GIREVE, for example, charges connection fees).

OICP comes with Hubject's commercial terms — partnership fees, per-transaction costs, and platform fees. The tradeoff is that you get a managed platform with business tooling included.

Can You Support Multiple Protocols?

Yes — and many organizations do. Supporting multiple protocols is common in the EV roaming ecosystem for several reasons:

Hub-Mediated Translation

Major roaming hubs act as protocol translators. When a CPO connected via OCPI needs to roam with an eMSP connected via OICP, the hub handles the translation. GIREVE and Hubject both support this kind of cross-protocol mediation.

This means you don't necessarily need to implement every protocol yourself. By connecting to a hub that bridges protocols, you can reach partners on different protocols through a single integration.

Multi-Hub Strategy

Some larger networks connect to multiple hubs simultaneously — for example, GIREVE via OCPI and Hubject via OICP — to maximize their roaming reach. This requires implementing and maintaining two protocol integrations, but it provides the widest possible partner network.

Practical Recommendation

For most organizations, start with OCPI. It gives you the broadest reach with a single implementation, and every major hub supports it. Add OICP later if you need deeper Hubject integration or Plug&Charge PKI services. There is almost never a reason to implement OCHP for a new integration.

How to Test Roaming Protocols

Testing roaming protocol implementations is challenging because it involves two-party communication with complex state machines. Common testing approaches include:

Sandbox environments: Most hubs offer sandbox or staging environments for testing. GIREVE and Hubject both provide test platforms where you can validate your implementation against simulated partners.

Conformance testing: The EVRoaming Foundation provides OCPI conformance tests. Hubject has its own certification process for OICP implementations.

Local simulation: For development and debugging, you need a way to simulate the other party in a roaming exchange. This is where tools like OCPPLab come in — our emulator supports OCPI testing, letting you simulate CPO and eMSP endpoints locally so you can validate your implementation before connecting to a production hub.

Testing roaming flows end-to-end — from driver authorization through session management to CDR settlement — requires simulating realistic scenarios across the full protocol lifecycle. Investing in proper test infrastructure early saves significant debugging time when you go live with real partners. For more on testing strategies, see our OCPP Testing Guide, which covers many of the same principles applicable to roaming protocol testing.

Frequently Asked Questions

Is OCPI replacing OICP and OCHP?

OCPI is replacing OCHP in most implementations — that trend is clear and accelerating. OCPI is not replacing OICP, however. Hubject continues to develop OICP and has a large, growing network. The two protocols coexist, with hubs bridging between them. Think of it as two competing standards, not one replacing the other.

Can I use OCPI without connecting to a hub?

Yes. OCPI supports direct peer-to-peer connections between a CPO and an eMSP. However, managing dozens of bilateral connections becomes impractical at scale. Most organizations use a hub for the majority of their roaming partnerships and maintain direct connections only for high-volume strategic partners.

What is the relationship between OCPP and OCPI?

OCPP manages communication between a charger and a backend system (CSMS). OCPI manages communication between backend systems for roaming. They operate at different layers: OCPP handles the physical charging infrastructure, while OCPI handles the business-to-business roaming layer. A typical CPO implements both — OCPP for their chargers and OCPI for their roaming connections.

How long does it take to implement OCPI?

A basic OCPI 2.2.1 implementation covering Locations, Tokens, Sessions, and CDRs typically takes 2-4 months for an experienced team. The timeline depends on your existing backend architecture, the number of modules you need, and whether you're integrating with a hub or establishing direct connections. Hub-specific requirements (credential exchange, registration flows) add additional time.

Is OICP only available through Hubject?

Yes. OICP is Hubject's protocol, and implementing it requires a partnership agreement with Hubject. You cannot use OICP independently of the Hubject platform. This is a fundamental architectural difference from OCPI, which is hub-agnostic.

Which protocol has better documentation?

OCPI's specification is publicly available on GitHub with detailed module descriptions, sequence diagrams, and examples. Community discussions and implementation guides are freely accessible. OICP's documentation is available only to Hubject partners. In terms of public resources and community support, OCPI has a significant advantage.

Summary

For new implementations, OCPI is the default recommendation. It is open, widely adopted, technically modern, and supported by every major roaming hub. Implement OICP in addition to OCPI if you need Hubject's Plug&Charge PKI or deeper access to the DACH and Asia-Pacific markets. Avoid OCHP unless you have a specific legacy integration requirement.

The EV charging roaming ecosystem is maturing rapidly. Protocols are converging around REST/JSON architectures, hubs are bridging across protocols, and the driver experience is becoming increasingly seamless. Whichever protocol you choose, the important thing is to start — roaming capability is quickly becoming table stakes for any serious charging network.

Related reading:

• What is OCPI? Open Charge Point Interface Explained
• GIREVE Hub Integration Guide
• CPO vs eMSP: Roles in EV Charging Explained
• What is OCPP? Open Charge Point Protocol Explained