Guides
Start typing to search…

Reporting & dashboards

Learn how to build tailored dashboards and reports to optimize your charging and eMobility operations

Via Spirii Connect, you gain access to powerful tools and APIs to visualize, analyze, and optimize your charging network. Whether you manage an EV fleet, operate multiple charging sites, or run an eMobility service, Spirii enables custom insights built around your business. Out-of-the-box, Spirii Connect provides:

  • A comprehensive business overview of revenue and utilization
  • Live operational dashboards for connector uptime and health
  • Export capabilities for charge detail records (CDRs) and financial reconciliation

However, we recognize that no two operators are alike. Your business may require custom KPIs, reporting flows, or real-time monitoring that go beyond what our standard solutions offer.

To support this, Spirii offers public APIs that let you extract, store, and analyze platform data your way.


Potential use cases include:

  • Creating a performance dashboard to identify growth opportunities and margin optimization
  • Building a real-time cockpit for your operational team to keep uptime as high as possible
  • Setting up automated end-of-month business reports for management
  • Tailoring a financial export for the accounting team

Key integration data

Below are the core API resources used for reporting and building customized dashboards.


Charge Detail Records (CDRs)

The GET CDRs will be the key endpoint for covering the above use cases.

A charge detail record (CDR) contains the data of a completed charging session. In Spirii, we populate the CDR with various contextual data to facilitate easy reporting and automation.

Useful data fields include:

  • Transaction ID (The unique ID of the CDR)
  • EVSE ID (the unique ID of the EVSE of the charger)
  • Consumed (the amount of kWhs consumed during the session)
  • Price data (range of data including the total charging price incl. and excl. VAT, currency, VAT rate, link to tariffs, etc.)
  • Location data (range of contextual data on the location of the charger)
  • Auth data (range of data on who charged on the charger and by which method)
  • Payment method and payment status (Status and method of the payment)
  • Voucher (data on charging by closed user groups and the discounted rate)
  • RoamingDetails (range of data included if the charging was done via roaming partners)
  • Co2 (The emitted CO2 per charging session, e.g. if the energy mix did not include 100% green energy)
  • HighestPowerDrawn (the peak amount of KW per charging session)

Use this endpoint to group the charging sessions for aggregated statistics across your network.


Additional integration data

Below are additional data resources that may be beneficial for your use case.


Locations

The GET Locations includes key metadata on the charging assets.

Each location represents a physical site with one or more chargers (EVSEs). The API provides site-level metadata useful for mapping, segmentation, and public/private status.

In the endpoint, you also get access to an array of the EVSEs on the site, including the real-time status of the individual connectors.

Useful data fields include:

  • Address and coordinates (where the assets are placed)
  • Publish (the public availability of the chargers)
  • Type (the location type to differentiate use cases)
  • EVSEs (array of EVSEs on the location and their current status)
    • Status (the current charging status, e.g. "available", "charging", or "faulted")
    • Error (range of data on the error code and information from the charger in case it's faulty)
  • Owner (the client who owns the location and the meter)

Use this endpoint to filter sessions by site or region, map site performance, and identify faults.


Transactions

The GET Transactions endpoint represents charging sessions in progress or recently completed (before they become CDRs). Useful for near real-time dashboards.

Useful data fields include:

  • EVSE ID (the unique ID of the EVSE of the charger)
  • Auth data (range of data on who charged, e.g., a specific app user or charge token)
  • Consumed (the amount of kWhs consumed so far during the session)
  • vehichleStateOfCharge (the latest battery percentage reading from the vehicle - only available on DC chargers)
  • Location data (range of contextual data on the location of the charger)
  • Roaming data (range of data if the session included roaming)

Use this endpoint to build live monitoring dashboards and proactive issue detection.


Tariffs

The GET Tariff includes key metadata on the charging price structure and conditions that impact the cost of charging.

Key data fields include:

  • Tariff ID (the ID of the tariff)`
  • Elements (array of data that includes the price components and restrictions of the tariff)
  • Currency (the currency of the charging price)

Use this endpoint to correlate session revenue with pricing strategy.


Sample reporting integration flow

Here is an example of how the integration flow could be set up:

  1. Live operations dashboard
    1. The client system schedules regular polling (e.g., every 1-5 minutes) for GET Locations and GET Transactions (using the lastUpdated and updated_at parameters respectively)
    2. Displays the current charger availability and faults
  2. Nightly reporting
    1. The client system triggers a cron job (e.g., end of day) that queries GET CDRs for new completed charging sessions for that day (using the updated_at parameter)
    2. Updates the statistics dashboard.
    3. Sends a daily usage report to the accounting or operational team
  3. Monthly reporting
    1. The client system aggregates stored CDRs for the month.
    2. Match relevant CDRs with tariff data from GET Tariffs.
    3. Creates a monthly report and sends it to management.

Best practices

Based on our experience, we have gathered a list of tips to ensure an optimal integration:

  • Map identifiers across platforms like location id, evse id for easier reporting and detection of duplicates.
  • Use incremental syncs with updated_at or pagination to avoid large payloads.
  • Store CDRs locally to reduce external API calls for frequent reporting.
  • Ensure retries and alerts are built in for critical triggers (like missing values).
  • Use rate limiting and avoid polling more than once per minute per resource.

Start integrating now and unlock smarter reporting and operations with Spirii. For guidance or assistance, check out our support resources or contact us directly.

Updated 25 days ago