Skip to content

Vemo OCPI Overview

flowchart LR
    subgraph Service Providers
        EMSP["eMSP<br/>(e-Mobility Service Provider)"]
        MSP["MSP<br/>(Mobility Service Platform)"]
    end

    subgraph Infrastructure
        CPO["CPO<br/>(Charge Point Operator)"]
        Hub["Roaming Hub"]
    end

    EMSP <-->|OCPI| CPO
    MSP <-->|OCPI| Hub
    Hub <-->|OCPI| CPO

OCPI (Open Charge Point Interface) is the roaming language that keeps e-mobility platforms aligned on locations, tariffs, tokens, and settlement data. The protocol lets charge point operators (CPOs), e-mobility service providers (eMSPs), and roaming hubs exchange information without handing control of their assets to a central broker. VEMO implements OCPI 2.2.1 with forward-compatibility for 2.3.0, following the canonical specification contained in docs/ocpi-spec.

Release Focus

  • 2.1.1 foundation — established core modules (Locations, Tariffs, Sessions, Tokens) and basic roaming flows . Use this version to onboard early partners and validate end-to-end connectivity.
  • 2.2.1 baseline — added command & control (CPO commands, eMSP commands), improved error handling, and introduced the Hub Client Info module for mediated topologies. Target this version for production deployments.
  • 2.3.0 deltas — introduces the Payments module, accessibility metadata (Parking object; disability-friendly EVSEs), ISO 15118 flags, and hub role hints in credentials. Map these changes before onboarding partners bound by 2025 legislation.

Note: VEMO does not currently implement OCPI 2.2's Smart Charging module. Reach out to the team if this functionality is required for your use case.

Market Roles & Identifiers

  • Platform-first model — OCPI models parties as “platforms” that bundle one or more roles (docs/ocpi-spec/terminology.asciidoc#terminology_roles). A single party can expose CPO and eMSP interfaces simultaneously.
  • Party & location IDs — every resource identifier is a structured CiString with strict length limits; e.g., Location.id (36 chars) plus Location.country_code and party_id. Validate IDs against shared registries to avoid 2003/3003 errors.
  • Token semantics — credentials tokens (used in HTTP Authorization) are distinct from driver tokens (mod_tokens). Keep onboarding checklists explicit about which identifier is being exchanged.

Topology Patterns

  • Direct roaming — bilateral peer-to-peer links minimize latency but require operational discipline as connections scale .
  • Hub mediation — OCPI 2.2 added routing headers so hubs can multiplex messages across many parties. Rely on the Hub Client Info module when you need consolidated partner metadata.
  • Hybrid meshes — some flows still run direct (e.g., bespoke commands) while commodity traffic goes through a hub. Document route choices so both parties know where to send retries.

Implementation Priorities

  • Discovery chain — the version and credentials endpoints must stay open to unauthenticated calls until the handshake completes. Cache their responses because partners hit them during monitoring.
  • Transport discipline — HTTPS + JSON with Base64 encoded authorization headers is mandatory (docs/ocpi-spec/transport_and_format.asciidoc#transport_and_format_authorization_header). Agree on pagination limits, rate expectations, and retry policies before moving to production.
  • Status contracts — raise OCPI-level status codes (1xxx/2xxx/3xxx/4xxx) alongside HTTP statuses . Add logging that correlates the two, otherwise debugging hubs becomes guesswork.

Where to Go Next

  • Protocol foundations — read protocol_meta_overview.md for transport, governance, and lifecycle guidance drawn from the spec’s meta sections.
  • Functional modules — modules_overview.md summarises responsibilities, payload owners, and sequence flows for each OCPI module.
  • Reference spec — the AsciiDoc sources in docs/ocpi-spec remain the single source of truth. Use this microsite to understand how VEMO applies the specification in practice.