OCPI Integration Patterns: Common Architectures

OCPI roaming architecture matters. The right architecture for a small regional operator looks different from the right architecture for a multi-national network. The right architecture for an eMSP differs from that of a CPO.

This article walks through the common OCPI integration patterns — what each looks like, when each fits, and the design considerations that distinguish them. If you are new to the protocol itself, start with what OCPI is; if you are weighing the core topology decision, the hub vs peer-to-peer comparison covers the trade-off in depth.

Pattern 1: Single bilateral P2P

The simplest pattern. Your OCPI endpoint connects to exactly one partner.

[ You ] <--- OCPI ---> [ Partner ]

When this fits:

• Pilot project or proof-of-concept.
• Strategic 1:1 partnership.
• Initial OCPI experience as a learning exercise.

Implementation:

• Single Credentials handshake.
• Per-module endpoints in your OCPI stack.
• One partner configuration entry.

Operational considerations:

• Per-partner monitoring is straightforward (only one partner).
• Outages affect only one relationship.
• Easy to debug; one side of the conversation to coordinate with.

Scaling limit: doesn’t scale beyond one partner without architectural changes.

Pattern 2: Multiple bilateral P2P

You connect directly to N partners, each with their own bilateral relationship.

[ You ] <--- OCPI ---> [ Partner A ]
        <--- OCPI ---> [ Partner B ]
        <--- OCPI ---> [ Partner C ]
        ...

When this fits:

• Small partner count (under ~10).
• Each relationship is strategic and warrants direct attention.
• Hub coverage doesn’t reach your target partners.

Implementation:

• Per-partner Credentials and configuration.
• Same OCPI stack, multiple partner entries.
• Per-partner monitoring and error handling.

Operational considerations:

• Coordination overhead scales linearly with partner count.
• Per-partner debugging and dispute resolution.
• Each partner upgrade (OCPI version, schema change) is its own project.

Scaling limit: practical limit around 15-20 partners before operational overhead dominates.

Pattern 3: Single hub

You connect to one hub. The hub mediates with many parties. See hub vs peer-to-peer OCPI for how a hub reshapes the Credentials and routing model.

[ You ] <--- OCPI ---> [ Hub ] --- OCPI --- [ Many partners ]

When this fits:

• You want broad reach with low overhead.
• One hub covers your target partner population.
• Operational simplicity is a priority.

Implementation:

• Single Credentials handshake with the hub.
• The hub appears as one partner in your configuration.
• Hub may pass through OCPI as-is or normalize/transform.

Operational considerations:

• One relationship to maintain.
• Hub fees vs P2P savings analysis.
• Hub becomes a single point of failure for many partnerships.
• Hub dependency for protocol evolution.

Scaling limit: scales by hub’s reach. Limit is how many partners the hub connects.

Pattern 4: Hub + selective P2P

You use a hub for the long tail but maintain direct P2P with select strategic partners.

[ You ] <--- OCPI ---> [ Hub ] --- OCPI --- [ Many small partners ]
        <--- OCPI ---> [ Strategic partner A ] (P2P)
        <--- OCPI ---> [ Strategic partner B ] (P2P)

When this fits:

• You have a few high-volume strategic partnerships and many smaller ones.
• Direct P2P for the strategic ones saves hub fees on high-volume traffic.
• Hub handles the long tail efficiently.
• This is the most common mature pattern.

Implementation:

• Hub configuration + per-strategic-partner configurations.
• Routing logic determines which path to use per partner.
• Often per-partner observability across both paths.

Operational considerations:

• Best of both worlds — operational simplicity for most, control for strategic.
• More complex than pure-hub.
• Important to keep behavior consistent regardless of routing path.

Scaling: scales well into hundreds of effective partners.

Pattern 5: Multiple hubs

You connect to two or more hubs simultaneously.

[ You ] <--- OCPI ---> [ Hub 1 ] --- OCPI --- [ Partners A1...An ]
        <--- OCPI ---> [ Hub 2 ] --- OCPI --- [ Partners B1...Bn ]

When this fits:

• No single hub covers all your target markets/partners.
• Geographic distribution — for example one hub strong in North America (reaching networks like ChargePoint, EVgo, Electrify America, Flo, and EV Connect) and another strong in Europe.
• Risk mitigation against single-hub dependency.

Implementation:

• Multiple hub Credentials handshakes.
• Per-hub configuration.
• Logic to route per-partner via the right hub if a partner is reachable through multiple.

Operational considerations:

• Multiple hub fees.
• More complex partner discovery (which hub reaches a given partner?).
• Better resilience.

Scaling: widest reach but most operationally complex.

Pattern 6: Multi-hub + selective P2P (full hybrid)

The most comprehensive architecture combining all patterns.

flowchart LR
    You[You]
    H1[Hub 1]
    H2[Hub 2]
    SA[Strategic A]
    SB[Strategic B]
    P1[Many partners]
    P2[More partners]
    You --> H1
    You --> H2
    You -.P2P.-> SA
    You -.P2P.-> SB
    H1 --> P1
    H2 --> P2
    style You fill:#dbeafe,stroke:#2563eb
    style SA fill:#dcfce7,stroke:#16a34a
    style SB fill:#dcfce7,stroke:#16a34a

When this fits:

• Multi-region operations.
• High partner count (50+).
• Strategic partnerships worth P2P investment.
• Operational maturity to manage the complexity.

Implementation:

• Multiple hub integrations plus per-P2P-partner integrations.
• Sophisticated routing logic.
• Full observability across all paths.

Operational considerations:

• High operational sophistication required.
• Best reach and resilience.
• Suitable for large operators / mature integrations.

Scaling: essentially unbounded; this is what major operators run.

Pattern 7: Hub-of-hubs

A hub that connects to other hubs, abstracting the multi-hub complexity from you.

[ You ] <--- OCPI ---> [ Meta-Hub ] --- OCPI --- [ Hub 1, Hub 2, ... ]

When this fits:

• You want broad multi-hub reach but with single-hub operational simplicity.
• A meta-hub provider exists in your region.

Implementation:

• Single OCPI integration with the meta-hub.
• Meta-hub abstracts the underlying hub mesh.

Operational considerations:

• Maximum simplicity but maximum dependency on meta-hub.
• Meta-hub fees on top of underlying hub fees.
• Less common in 2026; emerging in some markets.

Pattern 8: NAP-based (Europe)

Member-state National Access Points aggregate per-country data.

[ You ] <--- OCPI ---> [ Member State NAP ] --- [ All CPOs in country ]

When this fits:

• Europe-specific.
• AFIR-compliant data aggregation.
• Want canonical per-country views.

Implementation:

• OCPI integration with the relevant NAP.
• Per-country, since each member state has its own.
• Often combined with hub or P2P for actual roaming (NAP is primarily for data; roaming is separate).

Operational considerations:

• Mandatory for European operators in many cases.
• NAP integration may not cover all your roaming needs (just data).
• Combine with other patterns for full operations.

Architecture decision factors

A few questions to drive the right architecture choice.

How many partners do you want to reach?

• 1-5: P2P likely fine.
• 5-15: P2P or hub debatable.
• 15+: hub becomes valuable.
• 50+: multi-hub or hub + P2P hybrid.

Where are your partners geographically?

• Single country: one hub or P2P.
• Multi-country, same hub: one hub.
• Multi-region with hub gaps: multi-hub.

What’s your operational capacity?

• Small team: hub-mediated, fewer relationships.
• Large team: can manage multiple hubs + P2P.

What’s your strategic position?

• A few key partnerships drive most revenue: P2P for those.
• Long tail of small partnerships: hub.

What’s your risk tolerance?

• Low: multi-hub for resilience.
• High: single-hub is simpler.

What’s your budget?

• Tight: P2P (no hub fees).
• Comfortable: hub for operational simplicity.

Design considerations across patterns

A few principles that apply regardless of architecture.

Treat partners uniformly internally

Whatever routing your architecture uses, internal code should treat partners the same. The hub-vs-P2P distinction is configuration, not code path. Avoid embedding partner-specific logic deep in your stack.

Per-partner observability

Whether reached via hub or P2P, track each partner’s health independently. “Hub X is down” rarely is accurate — usually one specific partner via the hub is the issue.

Modular OCPI implementation

Your OCPI client/server code should be modular. Add a new partner = add configuration, not code.

Settlement abstraction

Whether settlement is bilateral, hub-mediated, or a mix, your internal billing should aggregate cleanly across all sources.

Migration paths

Architectures evolve. Start small, plan for growth. The right architecture in year 1 isn’t necessarily the right one in year 5.

Common architecture mistakes

A list of things that go wrong. Several of these overlap with the broader OCPI integration pitfalls ^{(coming soon)} that teams hit regardless of topology.

Over-engineering at the start. Multi-hub + P2P architecture for a small operator with 3 partners. Premature; complexity costs without benefit.

Under-engineering at scale. Pure P2P with 30+ partners. Operational drag exceeds the savings.

Single hub without backup. Hub goes down; significant fraction of business affected. Mitigate via multi-hub or P2P fallback for top partners.

Inconsistent behavior across routing paths. Same partner reachable two ways; behavior differs subtly. Confusing for support and partners.

No per-partner monitoring. Aggregate stats hide partner-specific issues.

Tight coupling to one hub’s quirks. Your code knows hub X’s specific behaviors; migrating becomes hard.

Migration patterns

How architectures evolve over time.

P2P → Hub: add a hub, gradually move long-tail partners to hub, keep top partners P2P.

Hub → Multi-hub: add second hub for coverage gaps, route specific partners to right hub.

Hub → Hub + P2P: promote top hub partners to direct P2P over time.

Reverse migrations are harder. Adding a hub is easier than removing one (partners may be hub-only).

Plan architecture with future evolution in mind.

The honest summary

OCPI integration architecture has many viable patterns, each fitting different operational contexts. Most mature operators converge on hybrid architectures combining hub-mediated long-tail with selective P2P for strategic partners. The right architecture for you depends on partner count, geography, capacity, and strategic position. Don’t over-engineer at the start; don’t under-invest as you scale; treat architecture as evolution rather than one-time decision.