Hub Receiver Identity (CPO)

When you push locations, tariffs, and sessions to ChargeIndia Hub, URL paths and object bodies use your CPO identity. Hub authenticates with the Hub token, then forwards the same CPO {country_code}/{party_id} to routed eMSPs.

For the shared model (auth = Hub, path = owning CPO), see Hub Receiver Identity.

Requirements

When pushing data to Hub:

1. Use your own CPO country_code and party_id in URL paths and object bodies.
2. Hub forwards the same identifiers to routed eMSPs. Do not use Hub (CIH) in path or body owner fields.
3. Include cdr_token with the eMSP's party on every session so Hub can route async delivery. Do not set cdr_token to Hub (CIH).

Copy token.country_code and token.party_id from the inbound START_SESSION command (or the authorize token) into session cdr_token. That identity is the eMSP that started the session, not your Hub credentials peer.

While your party is in active COMPATIBILITY grace, Hub may still deliver sessions/CDRs if cdr_token is Hub (CIH) by resolving the eMSP from a matching START_SESSION (authorization_reference, else token uid). This does not change OCPI path/auth semantics and is not available after you are marked COMPLIANT (or grace expires). Always send the real eMSP identity before exiting COMPATIBILITY.

Location forward example

You send:

PATCH /ocpi/2.2.1/locations/IN/CPO/LOC1/EVSE1
Authorization: Token {cpo-token}
Content-Type: application/json

{ "status": "CHARGING", "uid": "EVSE1" }

Hub forwards the same path and body to eMSP receivers. The path uses your identifiers, not Hub (IN / CIH).

Checklist

• [ ] Location/tariff/session pushes to Hub use your CPO {country_code}/{party_id} in path and body
• [ ] Session cdr_token identifies the correct eMSP on every update (never Hub CIH)
• [ ] cdr_token is copied from START_SESSION / authorize token, not from Hub credentials

Troubleshooting

Related docs

• Hub Receiver Identity (overview)
• CPO Integration Guide
• Locations
• Sessions
• CPO Migration