CPO Migration

This guide explains what changes for CPOs when you move from bilateral OCPI to roaming through ChargeIndia Hub. The protocol stays OCPI 2.2.1. The topology, credentials, and operational model change.

Why Hub

In peer-to-peer roaming, each CPO↔eMSP pair maintains its own credentials, URLs, and integration. On ChargeIndia Hub, you maintain one credentials relationship with the Hub. The Hub fans out your catalog and session data to connected eMSPs based on routing rules.

Aspect	Peer-to-peer	ChargeIndia Hub
Credentials	One exchange per eMSP	One exchange with Hub (`IN` / `CIH`, role `HUB`)
Traffic path	Direct CPO ↔ eMSP	Always via Hub
Catalog / sessions / CDRs	Push to each eMSP	Push to Hub only
Commands	Callback to each eMSP	Async results to Hub callback URL

OCPI version

ChargeIndia Hub supports OCPI 2.2.1 only. If your bilateral integrations use 2.1.1 or 2.2, plan a version cutover as part of migration.

Prerequisites

Commercial onboarding - Contact your ChargeIndia account team for an assigned country_code, party_id, and initial Hub token. See Onboarding.
Credentials exchange - Complete mutual registration with Hub. Remote role is HUB, not EMSP. See Authentication.
Receiver URLs - Provide tokens/commands receiver URLs where Hub should call your platform.
Routing enablement - Roaming only flows for pairs with an active routing rule. See Routing.
Connection health - Poll GET /ocpi/2.2.1/hubclientinfo before relying on live traffic. See Connection Health.

What changes

Area	Peer-to-peer	Via Hub
Outbound connections	N eMSP endpoint configs	One Hub base URL
Locations / tariffs / sessions / CDRs	Push to each eMSP	Push to Hub only
Token authorize	Receive from each eMSP	Receive from Hub only
Commands	Receive from each eMSP; callback to eMSP	Receive from Hub; async results to Hub callback URL
Inbound OCPI peer	Each eMSP	Hub only

Outbound calls to Hub

Module	Methods	What to push
Locations	`PUT`, `PATCH`	Locations, EVSEs, connectors
Tariffs	`PUT`	Pricing
Sessions	`PUT`, `PATCH`	Session state updates
CDRs	`POST`	Completed charge detail records

Every session must include a valid cdr_token with the eMSP's country_code and party_id. Without it, the Hub cannot route async session/CDR delivery.

Push using your own CPO country_code and party_id in URL paths and object bodies, do not use Hub (CIH). See Hub Receiver Identity (CPO).

Inbound from Hub

Module	Method	Purpose
Tokens	`PUT .../authorize`	Realtime authorization from eMSP via Hub
Commands	`POST .../commands/{command}`	Remote start, stop, reserve, cancel
Versions	`GET /ocpi/versions`	Hub health monitoring

Return immediate ACCEPTED or REJECTED for commands, then deliver async results to Hub, not directly to the eMSP:

POST /ocpi/2.2.1/commands/callback/{command_id}

Hub-initiated catalog pull

Hub operators can manually pull your Locations and Tariffs catalog. Ensure your version details advertise locations and tariffs with role SENDER if you rely on pull for initial sync.

Migration checklist

[ ] Bilateral eMSP credentials decommissioned (or idle) after Hub cutover per eMSP
[ ] Single Hub credentials exchange complete
[ ] All outbound pushes pointed at Hub base URL
[ ] Locations pushed for all public charge points (or Hub admin pull configured)
[ ] Location/tariff/session pushes use your CPO {country_code}/{party_id} in path and body
[ ] Tariffs pushed for pricing context
[ ] Token authorize endpoint live
[ ] Command receiver endpoints live
[ ] Command async callbacks sent to Hub callback URL (not eMSP)
[ ] Session PUT/PATCH with correct cdr_token on every session
[ ] CDR POST after session completion
[ ] GET /ocpi/versions reachable for health checks

Recommended cutover

Migrate incrementally - one eMSP at a time.

Onboard to Hub - Complete credentials exchange while keeping bilateral links active.
Enable routing - Ask your account team to enable routing for the first target eMSP.
Certify E2E - Run full session lifecycle via Hub. See Session Lifecycle and CPO Certification.
Switch traffic - Move production roaming for that eMSP to Hub.
Decommission P2P - Revoke bilateral credentials for that eMSP.
Repeat for the next eMSP.

Do not cut over before routing

Without an active routing rule, your pushes are stored but not exposed to unrouted eMSPs.