Introduction
The ChargePilot Push-API enables seamless cloud-to-cloud data transfer of billing-relevant charging session data. It is particularly relevant for customers who require automated access to completed charging session records for internal processing, billing, or reporting purposes.
By using this interface, customers can receive data from ChargePilot directly into their own systems without needing to poll an API or manually export data. This is especially beneficial for fleet operators, facility managers, and backend system integrators looking to streamline operational and billing workflows.
Use Case Summary
- Purpose: Automatically transmit completed charging session data from ChargePilot to the customer’s backend system.
- Data Format: JSON payload (see table below).
- Delivery Frequency: Every hour (default; can be adjusted based on customer needs).
- Trigger: Charging session completion.
Functionality
- Cloud-to-Cloud Data Transfer: ChargePilot automatically pushes billing-relevant charging session data to a customer-defined HTTPS endpoint.
- Automation: All current and future charging sites are automatically included in the data feed. No manual adjustments required after setup.
- Scalability: The setup supports customers with one or many sites and grows dynamically with their charging infrastructure.
Introduction Technical Requirements from Customer Side
To successfully enable the Push API, the following information must be provided:
01 API Key Header:
- The customer must provide an API key to secure the endpoint.
- This key must be passed using the header: Ocp-Apim-Subscription-Key
02 Endpoint URL:
- The customer must supply the HTTPS endpoint to which data should be pushed.
- Example: https://your-endpoint.customer.com
Data Format
The payload is sent as a JSON object. Each object represents one completed charging session.
The following table explains the key fields included in the payload:
Value | Example Data | Info | Data Type |
TransactionID | 7030760 | ID of the transaction, is in the StartTransaction and the StopTransaction | number |
ChargerID | TACW2242521T0570 | OCPP ID of the charging station, often the serial number of the charging station. | string |
ConnectorID | 1 | charging point | number |
StartAt | 2025-01-09T13:04:34.000Z | Time the StartTransaction occurred in UTC (= 9.1.2025, 14:04 Berlin time) | string |
EndAt | 2025-01-10T06:02:38.000Z | Time the StopTransaction occurred in UTC (= 10.1.2025, 7:02 Berlin Time) | string |
InitialSoC | null | only available for DC events | number | null |
Id | 56395736 | RFID tag that was used for this transaction | string |
EndSoC | null | only available for DC events | number | null |
EnergyDelivered | 17233 | Energy delivered in Wh. StartTransaction: meter_start: 0 / StopTransaction: Meter_stop: 17233 | number |
Integration Recommendations
- The setup should first be tested using the development environment to verify data reception and structure.
- Once confirmed, the configuration can be pointed to the production endpoint.
- Any changes to the endpoint or API key should be communicated in advance to ensure uninterrupted data delivery.
Was this article helpful?
That’s Great!
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
Feedback sent
We appreciate your effort and will try to fix the article