EV Charging Data: API or CSV?


As we consider how to submit reports for the CFR and BC LCFS regulations, and what data needs to be collected, we also need to think about how we collect this data. Generally what we are talking about here are charging sessions. How much energy was delivered to the vehicle, when was it delivered and over what time period?

Our use case involves two actors: Rewatt is the pull system acting as the credit creator, and needs access to charging sessions, so that it can be delivered properly to a 3rd party auditor and a regulator for oversight. The charging provider has a data-management system for their sites, which includes charging session data. How do the two systems talk to each other?

A seemingly simple solution might be to export and deliver a CSV once a year to Rewatt, maybe by email or possibly by publishing to a secure site, such as an Amazon S3 bucket. While CSV’s are great for one-off situations, it starts to become a bit of a problem once business starts to scale.

As the number of sites increases, each potentially with multiple chargers needing to be monitored regularly, their management becomes more difficult. Throw in multiple projects, some projects where not all the sites are included and we really need to add some automation to make sure everything is correct.

Things get even more complicated from the perspective of the credit creator, that is trying to ingest data from multiple organizations, for multiple projects, with 100% reliability and accuracy. Having a well-tested, secured and reproducibly accurate API integration can really alleviate a lot of the concerns. Let’s now look at each of these concerns, and touch on how it affects the credit creator and the charging provider.

  • Reliability
  • Scalability
  • Accuracy
  • Historicals
  • Error recovery
  • Normalization
  • Security
  • Effort


Even if the export of a CSV from your information system is automated, and perhaps it is uploaded to an S3 bucket, and maybe even that bucket is automatically ingested into the credit creation system automatically, there are some factors to consider. There are multiple systems involved, each with their own configurations and security requirements . Some programming is going to be required to make this all work seamlessly. And there are 3 points of failure.

Alternatively, a manual export and manual upload is a human activity, which is always subject to some error, as well as a lack of predictability. While it can work, it tends not be particularly reliable, and requires human intervention.

In contrast, an API is purely machine to machine, with only 2 points of failure, and since a contract is enforced and well-tested, is entirely predictable and reliable, after a one-time setup.


As the number of sites increases, one can simply increase the number of rows in a sheet. Easy enough. But what if we wanted to increase the frequency of export? Or what if we wanted to limit which sites are exported? And what if we wanted a large number of sites over a longer or shorter time period? While doable, it requires work. With an API implemented, the work is already done! Additionally, it is is very easy to rate-limit your API, which can be critical during scaling.


This generally boils down to ease of repeatability. Once an API is implemented and tested and found to adhere to its contract, accuracy will be very high over an ongoing basis.

A CSV export, which if automated, should be similarly accurate. If manual, then we introduce uncertainty around time periods, possibly timezones, number handling, human error and more.


With an API, this is simply a matter of querying for the appropriate dates, which is generally already a part of the automated data collection process.

With a CSV, a special request to the IT department would likely need to be made for the appropriate dates and sites, then manually ingested.

Error Recovery

If for any reason either system suffers failure, we may need to recover some missed data. Consider a case where a CSV is published once a month, but a month is missed. In all likelihood, solving the problem this will involve human intervention, such as a manual. With an API, this is automatic – the credit creator will simply retry later until it works.


A very specific set of fields with accompanying units is required for accurate conversations between two systems. This can be accomplished with some light programming in either an automated CSV solution or an API solution. With a manual CSV solution, this will be prone to error, as human intervention is required.


Charging Provider

Exporting a CSV manually from a data-management system is not usually problematic. Choose the correct date range, choose the correct chargers, choose the correct fields and formatting, and you’re done. Just email it to the credit creator.
An automated CSV export solution, with an upload to a cloud bucket, requires some light programming and security considerations.
An API integration would take some more involved programming, especially when thinking around access to the API. If your data is already in the cloud though, such as AWS or GCP, there are built-in solutions for creating secure APIs.
Credit Creator
The API integration is written once, well-tested and secured. Adding new integrations to new charging providers is almost no effort, provided the same charging API is used.
If using a manual CSV option, Rewatt either needs to build a CSV integration and publish specs on its format, possibly build a CSV uploader, along with the ability to handle errors and mistakes, or has to do a manual import.
With an automated CSV solution, there would be some configuration and security to deal with, for a relatively light lift, but separate from all the other systems.


The question for the charging provider: is it worth the extra time to implement an API, rather than export a CSV? For anything more than a one-time delivery, the answer must be yes. The improved reliability, scalability, error-recovery, and avoidance of human intervention quickly recoups the investment.

For the credit creator, the answer is unequivocally yes – they get access to reliable, accurate, formatted data with fault-tolerance, without doing anything (this integration is already done for multiple providers).

Finally, for the auditor, they love the idea of getting automated, reliable data, rather than human-prepared data, for all the same reasons.
You can look at Rewatt’s Charging API spec here, and get an idea of what’s involved implementing it for your own system.


Related Articles