Hub Receiver Identity (eMSP)

When Hub forwards catalog and session data to your platform, inbound calls use the Hub token for auth and the owning CPO's {country_code}/{party_id} in URL paths. Do not validate path parties against credentials roles alone.

For the shared model, see Hub Receiver Identity.

P2P vs Hub

Aspect	Peer-to-peer	Via ChargeIndia Hub
Credentials	One exchange per counterparty	One exchange with Hub (`HUB` role)
Inbound auth token	Counterparty token	Hub token
Path `{cc}/{pid}` on catalog/session push	Direct peer's party	Owning CPO
Valid path parties	From bilateral credentials	From routing + HubClientInfo
Inbound OCPI peer	Each counterparty	Hub only

Per-module path behavior

Module	Direction	Path party	Notes
Locations	Hub → eMSP	CPO	Same `PUT`/`PATCH` method and body as CPO sent to Hub
Tariffs	Hub → eMSP	CPO	`PUT` preserved
Sessions	Hub → eMSP	CPO	`PUT`/`PATCH` preserved
CDRs	Hub → eMSP	CPO in body	`POST` - no path party
Commands callback	Hub → eMSP	n/a	`POST` to eMSP `response_url`
Token authorize	eMSP → Hub	CPO in path	Hub forwards to owning CPO
Commands	eMSP → Hub	n/a	`POST /commands/{command}` - no path party

Location forward example

Concrete request Hub sends to your locations RECEIVER:

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

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

The path uses CPO identifiers (IN / CPO), not Hub (IN / CIH) and not your eMSP party id.

Requirements

When implementing receivers on your platform:

Authenticate inbound calls with the Hub token from credentials exchange.
Do not require URL {country_code}/{party_id} to match credentials roles.
Accept {cc}/{pid} for any routed CPO - intersect routing rules with parties listed in HubClientInfo.
Poll GET /ocpi/2.2.1/hubclientinfo to build and refresh your CPO allow-list. Hub does not push HubClientInfo; you pull it.
Treat CONNECTED (and optionally PLANNED during pre-provisioning) CPOs as valid path parties.
Make receivers idempotent - Hub may retry on transient failures. See Async Delivery.

Checklist

[ ] Location/tariff/session receivers accept CPO {country_code}/{party_id} in URL path
[ ] Receiver validation uses HubClientInfo + routing allow-list (not credentials roles only)
[ ] Inbound calls authenticated with Hub token only (not per-CPO tokens)
[ ] Test inbound location PATCH from Hub with a routed CPO party key

Troubleshooting

Symptom	Likely cause	Fix
`Invalid CountryCode & PartyId combination` (HTTP 400) on location/tariff/session receiver	P2P-style validation: path party must match credentials `roles`	Accept CPO keys from HubClientInfo + routing; authenticate Hub token
Location push succeeds on Hub but your catalog never updates	Receiver rejecting path party	Fix receiver validation per this page
Empty catalog on `GET`	No routing rule	Contact account team to enable routing
Session not received	Missing `cdr_token` on CPO session push	Ask the CPO to set eMSP identity on the session

Common migration mistake

In peer-to-peer mode, the authenticated party and the path party are usually the same counterparty. Via Hub, they are different: auth = Hub, path = CPO. This is expected OCPI Hub behavior, not a misconfiguration on the Hub side.