eMSP Migration

This guide explains what changes for eMSPs 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 traffic to connected CPOs based on routing rules.

Prerequisites

1. Commercial onboarding - Contact your ChargeIndia account team for an assigned country_code, party_id, and initial Hub token. See Onboarding.
2. Credentials exchange - Complete mutual registration with Hub. Remote role is HUB, not CPO. See Authentication.
3. Receiver URLs - Provide sessions/CDRs/locations/tariffs receiver URLs where Hub should call your platform.
4. Routing enablement - Roaming only flows for pairs with an active routing rule. See Routing.
5. Async delivery - Receivers must be idempotent. See Async Delivery.
6. Party identity on inbound pushes - Accept owning-CPO path parties; do not validate against credentials roles alone. See Hub Receiver Identity (eMSP).
7. Connection health - Poll GET /ocpi/2.2.1/hubclientinfo before relying on live traffic. See Connection Health.

What changes

Outbound calls to Hub

Token authorization path - use the owning CPO's identifiers:

PUT /ocpi/2.2.1/tokens/{cpo_country_code}/{cpo_party_id}/{token_uid}/authorize

Inbound from Hub

Implement standard OCPI receivers, but accept calls only from Hub:

Command async results arrive at your response_url, forwarded by Hub from the CPO callback, not directly from the CPO.

When Hub forwards catalog and session updates, URL paths use the owning CPO's country_code and party_id. Authenticate with your Hub token, then validate the path party against routed CPOs via GET /hubclientinfo. See Hub Receiver Identity (eMSP).

Keep GET /ocpi/versions reachable for Hub health probes.

Migration checklist

• [ ] Bilateral CPO credentials decommissioned (or idle) after Hub cutover per CPO
• [ ] Single Hub credentials exchange complete
• [ ] All outbound OCPI pointed at Hub base URL
• [ ] Routing rules enabled for target CPOs
• [ ] Token authorization flow tested via Hub
• [ ] START_SESSION / STOP_SESSION tested end-to-end via Hub
• [ ] Session, CDR, location, and tariff receiver endpoints live and idempotent
• [ ] Location/tariff/session/CDR pull integrated for backfill
• [ ] HubClientInfo polled for counterparty availability
• [ ] Location/tariff/session receivers accept CPO {country_code}/{party_id} in URL path
• [ ] Receiver validation uses HubClientInfo + routing allow-list (not credentials roles only)
• [ ] Test inbound location PATCH from Hub with a routed CPO party key
• [ ] GET /ocpi/versions reachable for health checks

Recommended cutover

Migrate incrementally - one CPO at a time.

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

Related docs

• eMSP Integration Guide
• Hub Receiver Identity (eMSP)
• eMSP Certification
• Async Delivery
• CPO Migration
• Onboarding
• Routing