Async Delivery

Sessions, CDRs, locations, and tariffs follow an async push model on ChargeIndia Hub for eMSP receivers. eMSPs can also pull locations, tariffs, sessions, and CDRs from the Hub as backfill.

How it works

CPO pushes data to Hub API
Hub stores the record and enqueues a forward job
Worker resolves target eMSP(s) from routing rules (and cdr_token for sessions/CDRs)
Worker calls the eMSP's receiver endpoint with the payload

Path {country_code}/{party_id} segments identify the owning CPO, not the Hub. The Hub authenticates with the eMSP's Hub token but preserves the CPO party key from the original CPO push. See Hub Receiver Identity (eMSP).

What is pushed asynchronously

Data	CPO action	eMSP receives
Location updates	`PUT` / `PATCH` locations (location, EVSE, connector)	Same method/path/body on eMSP locations RECEIVER (path uses CPO `{cc}/{pid}`)
Tariff updates	`PUT /tariffs/{cc}/{pid}/{id}`	`PUT` to eMSP tariffs RECEIVER (path uses CPO `{cc}/{pid}`)
Session updates	`PUT` / `PATCH` sessions	Same method + body to eMSP sessions RECEIVER (path uses CPO `{cc}/{pid}`)
CDRs	`POST /cdrs`	`POST` to eMSP CDRs module

EVSE status PATCH updates are debounced (~3s) per location/EVSE/eMSP before forward to reduce noise.

Locations with publish: false are stored but not forwarded.

Receiver requirements

eMSPs must implement and register:

PUT    /ocpi/2.2.1/locations/{country_code}/{party_id}/{location_id}
PATCH  /ocpi/2.2.1/locations/{country_code}/{party_id}/{location_id}
PATCH  /ocpi/2.2.1/locations/.../{location_id}/{evse_uid}
PATCH  /ocpi/2.2.1/locations/.../{evse_uid}/{connector_id}
PUT    /ocpi/2.2.1/tariffs/{country_code}/{party_id}/{tariff_id}
PUT    /ocpi/2.2.1/sessions/{country_code}/{party_id}/{session_id}
PATCH  /ocpi/2.2.1/sessions/{country_code}/{party_id}/{session_id}
POST   /ocpi/2.2.1/cdrs

Provide these URLs during onboarding.

Pull backfill

If your receiver was down, queued forwards are retried. You can also backfill with GET /sessions and GET /cdrs on the Hub (scoped to your party via cdr_token), plus GET /locations and GET /tariffs for catalog data.

Routing dependency

Async delivery requires:

Active routing rule for the eMSP↔CPO pair
Configured eMSP RECEIVER URL in the Hub registry
For sessions/CDRs: valid cdr_token identifying the eMSP

Latency and retries

Metric	Target
Hub → eMSP delivery (p95)	< 5 seconds
Retry on failure	Yes, via queue with backoff

If delivery fails repeatedly, contact your account team. Undelivered messages may end up in a dead-letter queue for manual re-drive.

Idempotency

Design your receivers to be idempotent. The Hub may retry delivery on transient failures. Use location_id, tariff_id, session_id, and CDR id as deduplication keys.