CDRs

Endpoints

Hub role: RECEIVER (CPO → Hub) + SENDER (Hub → eMSP async)

There is no GET /cdrs for eMSPs on the Hub. eMSPs receive CDRs via async push.

CPO push example

POST /ocpi/2.2.1/cdrs
Authorization: Token {cpo-token}
Content-Type: application/json

{
  "country_code": "IN",
  "party_id": "ABC",
  "id": "CDR001",
  "start_date_time": "2025-06-23T10:00:00.000Z",
  "end_date_time": "2025-06-23T10:45:00.000Z",
  "session_id": "SESSION001",
  "cdr_token": {
    "country_code": "IN",
    "party_id": "XYZ",
    "uid": "TOKEN001",
    "type": "RFID",
    "contract_id": "CONTRACT001"
  },
  "cdr_location": { ... },
  "currency": "INR",
  "total_cost": { "excl_vat": 150.0, "incl_vat": 177.0 },
  "total_energy": 12.5,
  "total_time": 2700,
  "last_updated": "2025-06-23T10:45:00.000Z"
}

Async delivery to eMSP

After CPO POST, the Hub worker forwards to:

POST /ocpi/2.2.1/cdrs

on the eMSP's registered receiver URL.

Immutability

CDRs are treated as immutable audit records at the Hub. Corrections require a new CDR or bilateral agreement outside the Hub.

Required: cdr_token

Same as sessions — cdr_token must identify the eMSP for routing.

India notes

• Use INR for currency
• GST fields may be included for downstream invoicing; the Hub does not generate invoices

See India Conventions.

Related docs

• Session Lifecycle
• Async Delivery

OCPI spec

See OCPI 2.2.1 CDRs module for full CDR object definitions.