Sessions and CDRs follow an async push model on ChargeIndia Hub. eMSPs do not pull these from the Hub — the Hub worker delivers them to your receiver endpoints.

How it works

flowchart LR
  CPO[CPO pushes to Hub] --> HubAPI[hub-api stores]
  HubAPI --> Queue[SQS queue]
  Queue --> Worker[worker forwards]
  Worker --> eMSP[eMSP receiver]

CPO pushes session (PUT) or CDR (POST) to Hub API
Hub stores the record and enqueues a forward job
Worker resolves the target eMSP from cdr_token and routing rules
Worker calls the eMSP's receiver endpoint with the payload

What is pushed asynchronously

Data	CPO action	eMSP receives
Session updates	`PUT /sessions/{cc}/{pid}/{id}`	`PUT` to eMSP sessions module
CDRs	`POST /cdrs`	`POST` to eMSP CDRs module

Receiver requirements

eMSPs must implement and register:

PUT  /ocpi/2.2.1/sessions/{country_code}/{party_id}/{session_id}
POST /ocpi/2.2.1/cdrs

Provide these URLs to your account team during onboarding.

There is no GET /sessions or GET /cdrs on the Hub for eMSPs. If your receiver is down, data is retried — but you cannot backfill by polling the Hub.

Routing dependency

Async delivery requires:

Valid cdr_token on the session/CDR identifying the eMSP
Active routing rule for the eMSP↔CPO pair
Configured eMSP receiver URL in the Hub registry

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 session and CDR receivers to be idempotent. The Hub may retry delivery on transient failures. Use session_id and CDR id as deduplication keys.