ChargeIndia Hub DocsChargeIndia Hub uses a routing matrix (allow-list) to control which eMSPs can roam with which CPOs. This is a core pilot and production control mechanism.
This page describes the default via-Hub roaming path: catalog and lifecycle traffic both go through the Hub.
OCPI Message Routing headers
Separately from this allow-list, OCPI 2.2.1 defines OCPI-from-* / OCPI-to-* headers for party-to-party routing via a Hub. Those headers are optional on inbound calls (Open Routing when OCPI-to-* is omitted). See Authentication — Message routing headers.
How routing works
When an eMSP requests data or initiates an action involving a CPO, the Hub checks whether a routing rule exists for that eMSP↔CPO pair.
| If rule exists | Behavior |
|---|---|
| Yes | Request proceeds; data is visible or action is forwarded |
| No | Request fails or returns empty, partner is not visible |
Configured by account team
Routing rules are configured by your ChargeIndia account team. Contact them to enable roaming with specific partner networks.
What routing affects
eMSP visibility
| Module | Routing impact |
|---|---|
| Locations | GET /locations returns only CPOs with active routing rules |
| Tariffs | GET /tariffs returns only routed CPO tariffs |
| Tokens | Authorization forwarded only to routed CPOs; if not routed, Hub returns allowed: NOT_ALLOWED (not "Not routed") |
| Commands | Commands forwarded only to routed CPOs; if not routed, Hub returns "Not routed" (HTTP 403). Destination defaults from body (location_id / session_id); optional OCPI-to-* must agree when sent. |
| Sessions/CDRs | Async push to eMSP only when session CDR token identifies a routed pair |
CPO behavior
CPOs push locations, sessions, and CDRs to the Hub regardless of routing. The Hub stores all data but only exposes it to eMSPs with active rules.
Session and CDR routing
Sessions and CDRs include a cdr_token with country_code and party_id identifying the eMSP. The Hub uses this to determine which eMSP receives async pushes.
Ensure cdr_token is set correctly on every session and CDR push, incorrect values will prevent delivery to the intended eMSP.
Example
| eMSP | CPO | Routing rule | eMSP can see CPO locations? |
|---|---|---|---|
| EMSP-A | CPO-1 | Active | Yes |
| EMSP-A | CPO-2 | Active | Yes |
| EMSP-B | CPO-1 | Not configured | No |
| EMSP-B | CPO-2 | Active | Yes |
Troubleshooting
| Symptom | Hub response | Likely cause |
|---|---|---|
| Empty location list | Empty data | No routing rules for your eMSP↔CPO pairs |
| Authorize blocked for a CPO | allowed: NOT_ALLOWED | Target CPO not in your routing matrix (not "Not routed") |
| Command blocked for routing | HTTP 403, "Not routed" | No routing rule for the eMSP↔CPO pair |
| Session/CDR not received by eMSP | CPO may still get 1000 | Missing or incorrect cdr_token on CPO push |
Verify routing with your account team. Full contracts: Session Lifecycle — Failure scenarios.