Getting utility data out of a utility is half the job. The other half is getting it into the system where someone will actually use it: a benchmarking tool, a BI dashboard, a CRM, an ERP, or an ESG reporting platform. The delivery method you choose decides how much of that second half is automated and how much is a person downloading files on the first of the month.
This guide compares the three delivery methods EZGB supports, REST API, SFTP, and CSV, explains what each one is good for, and then follows the data into the destinations we see most often. The goal is to help you pick a method before the first account is connected, because switching later usually means rebuilding an import.
Where the data comes from
EZGB collects consumption and billing data from utilities through authorized utility connections, Green Button (Download My Data and Connect My Data), and PDF bill digitization for accounts with no digital feed. In Ontario, Green Button data arrives as ESPI XML; the Green Button Alliance describes the standard as a common XML format plus a data exchange protocol, with interval data at 5-minute, hourly, daily, or monthly resolution depending on the provider. Enbridge Gas, for example, produces one or two XML files per download, one for account details and one for billing and usage, covering up to 24 months.
Raw XML in several utility flavours is not what your downstream system wants. EZGB standardizes everything into consistent units and fields first: one schema for accounts, meters, interval reads, and billing periods, whether the source was a Green Button feed or a scanned bill. Delivery is the step after that. The raw structure is described in our earlier post on the Green Button data format, if you want to see what is being normalized.
The three delivery methods
REST API (JSON)
An API is the right choice when your own software needs the data on demand or as soon as it changes. Your backend calls an endpoint, authenticates, and receives JSON for the accounts, meters, and periods you ask for. It fits products that show utility data to their own users, systems that recalculate when a new bill lands, and any workflow where a person should never have to touch a file. The trade is that someone on your side writes and maintains the client code.
SFTP
SFTP suits organizations that already run scheduled file-based integrations: an ERP that ingests from a drop folder, a data warehouse with a nightly load, or an IT team that prefers files over API keys. EZGB places files on a schedule, your process picks them up, and nothing depends on a live call succeeding at the moment a user clicks. It is the most common choice for finance and sustainability teams inside larger organizations.
CSV
CSV is the universal fallback. Every spreadsheet, BI tool, and benchmarking platform can read it. It is the right choice for smaller teams, for one-time historical loads, and for tools whose import path is a file upload. The caveat is that CSV is looser than people assume. RFC 4180, the document that finally described the format, notes that while this format is very common, it has never been formally documented and that there are considerable differences among implementations. A consistent, documented column layout matters more than the file extension, which is why EZGB's CSV output uses the same field names and units as its API.
Choosing a method
| Delivery | Best for | Cadence | What you need on your side |
|---|---|---|---|
| REST API (JSON) | Your own software, dashboards, anything on demand | On request, or polled on your schedule | A developer to write and maintain the client |
| SFTP | ERPs, warehouses, scheduled batch loads | Scheduled drops (daily, weekly, monthly) | A drop folder and an import job |
| CSV | Spreadsheets, BI tools, upload-based platforms | Scheduled export or on demand | A person or process to load the file |
Most organizations end up with two methods, not one: an API or SFTP feed for the system of record and CSV exports for ad hoc analysis. That is fine, provided both come from the same standardized dataset so that the numbers agree.
Where the data goes next
ENERGY STAR Portfolio Manager
Benchmarking and Ontario reporting run through Portfolio Manager, and the tool is strict about inputs. Natural Resources Canada's FAQ states that a score requires at least 12 full consecutive calendar months of energy data with meters that account for all fuel types. Ontario's reporting guide tells building owners to enter data from January 1 through December 31 and to run the Portfolio Manager Data Quality Checker before submitting; ENERGY STAR notes that more than 70 data quality checks are performed. Delivering complete, gap-free monthly data is what makes that step boring, which is the goal. See getting utility data into ENERGY STAR Portfolio Manager for the details.
Power BI and other BI tools
Power BI Desktop's File category lists Excel Workbook, Text/CSV, XML, and JSON connectors, and its Other category includes Web and OData Feed. That means a CSV drop, an SFTP-delivered file, or a JSON API response can all feed a Power BI model. For a dashboard that refreshes without anyone uploading anything, point Power BI at the API or at the SFTP-delivered files on a shared location. The utility data in Power BI guide shows a working model.
CRMs and custom applications
Sales and customer success teams want usage next to the account record: how much a customer uses, when their bill arrived, whether consumption changed. That is an API job. Your integration writes standardized consumption and billing fields onto the account object, and the CRM does the rest. The connecting Green Button data to a CRM or custom app post covers the mapping.
ERPs and finance systems
Finance cares about the billing side: charges, periods, and account numbers that reconcile to invoices. The Green Button usage summary carries fields such as payments, generation and distribution charges, tariff name, demand charges, and third-party charges, and bill digitization captures the same from PDFs. SFTP delivery into the ERP's import folder is the usual pattern, because finance systems are built around scheduled batch loads.
ESG and emissions reporting
Emissions reporting needs consumption by fuel, by site, by period, in consistent units. Deliver that as a monthly file or through the API and the emissions calculation becomes a multiplication rather than a data-gathering project. The calculating GHG emissions from utility data post explains the factors and the arithmetic.
RETScreen
Energy analysts modelling a retrofit want monthly consumption and cost history per site in a shape they can paste or import. CSV is normally the right delivery here, and the utility data for RETScreen guide walks through it.
A short setup checklist
- List every destination system and who owns it. The system of record decides the primary delivery method.
- Decide the cadence for each destination: on demand (API), scheduled (SFTP), or manual (CSV).
- Agree on identifiers. Utility account numbers, meter numbers, and your own site IDs must map consistently across every file and call.
- Confirm units and time zones once, in the standardized schema, rather than in each destination.
- Plan for corrections. Utilities re-issue bills and re-read meters; your import should update rather than duplicate.
- Keep the raw source. Even when you consume standardized data, retain the original XML or bill image for audit.
If you are unsure which combination fits your systems, book a walkthrough at ezgb.ca. We will look at your destinations and recommend a delivery setup before any accounts are connected. EZGB is part of MartinAI / Screaming Power, and where a destination needs a custom interface, MartinAI builds it.
Frequently asked questions
Is an API always better than SFTP or CSV?
No. An API is better for on-demand access inside your own software. SFTP is better for scheduled batch systems that already work from files. CSV is better when the destination's import path is a file upload or a spreadsheet. Pick by destination, not by preference.
Can I get the same data through more than one method?
Yes, and most organizations do. The important thing is that every method draws from the same standardized dataset, so a CSV export and an API response for the same account and period agree to the unit.
How do I handle utilities that are not on Green Button?
Accounts without a digital feed are covered by PDF bill digitization, which produces the same standardized fields. Delivery is identical: the destination cannot tell whether a record came from a Green Button feed or a scanned bill, which is the point.
Does the delivery method affect data quality?
Not directly, but it affects how quickly you notice problems. An API integration can flag a missing period the day it should have arrived. A monthly CSV may not be opened until reporting season. Whatever the method, validate for gaps and overlaps on arrival, and treat a missing period as an alert rather than a footnote.
What about water and natural gas?
The same delivery methods apply. Green Button Connect My Data covers electricity, natural gas, and water usage data where a utility publishes it, and PDF digitization covers the rest, so multi-commodity portfolios arrive through one feed.
Sources
- RFC 4180: Common Format and MIME Type for Comma-Separated Values (CSV) Files
- Microsoft Learn: Data sources in Power BI Desktop
- Green Button Alliance: Green Button standards
- Green Button Alliance: Green Button Connect My Data (CMD)
- Enbridge Gas: Download and share your data
- Natural Resources Canada: Benchmarking frequently asked questions
- Ontario.ca: How to report (Guide to energy and water reporting)
- ENERGY STAR: List of Portfolio Manager alerts
Source: rfc-editor.org