Every software team that touches energy eventually asks the same question. You need your customers' electricity, gas, or water data from their utilities. Do you write the integrations yourself, one utility at a time, or do you put a utility data aggregator between your product and the utilities and consume one API? The honest answer depends on how many utilities you need, how fast you need them, and how much of your engineering time you are willing to spend on work that your customers will never see.
This guide lays out the decision the way an experienced integration lead would. It covers what a single utility connection actually involves in Ontario, why the count of utilities matters more than any single integration, what an aggregator does and does not do for you, and a short checklist for deciding. If you already know you need a build, the utility data API for energy software page describes the delivery side in more detail.
What one utility integration really involves
The good news in Ontario is that the data format is standardized. Green Button is based on the Energy Services Provider Interface (ESPI) standard that the North American Energy Standards Board released in the fall of 2011, and the Green Button Alliance describes it as a common XML format for usage data plus a data exchange protocol for automatic transfers with customer authorization. The data can arrive in 5-minute, hourly, daily, or monthly intervals, depending on what each provider decides to publish.
The less good news is that a standard format does not remove the per-utility work. For Connect My Data, the ongoing authorized feed, each utility runs its own third-party onboarding. Toronto Hydro, for example, states that a company wanting to register as a Green Button application provider must submit an online application, complete a connectivity test, and comply with its Third-Party Terms and Conditions. Those terms include obligations such as maintaining insurance coverage and honouring a customer's right to revoke authorization independently at any time. Multiply that by every distributor your customers are served by and the pattern becomes clear: the format is shared, the relationships are not.
On top of onboarding, a build has to handle the authorization flow. Connect My Data uses OAuth, which RFC 6749 describes as a framework that enables a third-party application to obtain limited access to an HTTP service on behalf of a resource owner. In practice that means redirect handling, token storage, refresh logic, and revocation handling for each utility endpoint. The OAuth authorization in Green Button Connect My Data guide walks through that flow step by step.
The checklist for a single utility
- Third-party registration, connectivity testing, and acceptance of that utility's terms
- An OAuth client, redirect URIs, token storage, and refresh and revocation handling
- A parser for the utility's ESPI XML output, including interval blocks and usage summaries
- Handling of the utility's history window (Hydro Ottawa, for instance, offers up to 24 months of usage and billing data)
- Monitoring for endpoint changes, certificate rotations, and outages
- A support path for customers whose accounts fail to link
Why the number of utilities is the real cost driver
If your customers were all served by one distributor, building in-house would be reasonable. They are not. The Green Button Alliance reported in November 2023 that 55 Ontario-based utility platforms had been certified, covering nearly 5.4 million residential and business electricity customers and over 3.5 million natural gas customers. Its earlier announcement of the Ontario regulation described 60+ regulated utilities province-wide. The Ontario Energy Board confirms that rate-regulated electricity and natural gas utilities were required to provide Green Button access by November 1, 2023.
That is the scale problem. A product serving Ontario businesses cannot pick three utilities and stop; a single customer with sites in Toronto, Ottawa, and rural Ontario touches three distributors and a gas utility. Each one is a registration, a connectivity test, a set of terms, and a maintenance commitment. And Ontario is only the start if your customers have sites in other provinces, where the Green Button Alliance reports no confirmed Green Button deployments and utility portals differ.
The onboarding utility accounts at scale guide covers the operational side: what it takes to link hundreds of accounts across many utilities without a support queue that never empties.
What an aggregator does for you
A utility data aggregator holds the utility relationships so that you do not have to. It is registered as a third party with each utility, maintains the OAuth clients and endpoints, parses each utility's output, and gives you one interface. EZGB is built this way. It collects consumption and billing data from utilities through authorized utility connections, Green Button (both Download My Data and Connect My Data), and PDF bill digitization for accounts where no digital feed exists. It standardizes the result into consistent units and fields and delivers it by REST API (JSON), CSV, or SFTP, plus embeddable components, into ENERGY STAR Portfolio Manager, RETScreen, Power BI, CRMs, ERPs, and ESG platforms. EZGB is part of MartinAI / Screaming Power, and MartinAI builds custom interfaces when a product needs one.
The point of the aggregator is not that it is clever. It is that the per-utility work is done once, for everyone, and your team works against a single shape of data. When a utility changes something, the aggregator absorbs it. When a customer adds a site served by a utility you have never heard of, your code does not change.
What an aggregator does not remove
- Customer consent. The customer still has to authorize sharing. The Green Button Alliance notes that customers define the length of that authorization and can revoke it at any time, and the OEB adds that a customer can revoke by contacting their utility. Your product should be designed for that.
- Data gaps. Some accounts sit with utilities that are exempt, or the customer only has paper bills. An aggregator that also digitizes PDF bills closes most of those gaps, but not every account is digital on day one.
- Your own data model. You still decide how sites, accounts, and meters map to your product, and how you handle history, estimates, and corrections.
A side-by-side comparison
| Question | Build your own | Use an aggregator |
|---|---|---|
| Time to first utility | Weeks to months (registration, testing, OAuth, parsing) | Much shorter: one API, one authorization flow |
| Time to 50 utilities | Years of accumulated effort and maintenance | Does not grow per utility |
| Who holds the utility relationships | You | The aggregator |
| Coverage for accounts without a digital feed | Separate project (bill scanning) | Included when the aggregator digitizes PDF bills |
| Output format | Whatever you build, per utility | One standardized schema by API, CSV, or SFTP |
| Ongoing maintenance | Your team, per utility | The aggregator |
| Control over raw data | Full | Full raw plus standardized, depending on delivery |
When building still makes sense
There are cases where a build is right. If your product serves customers of exactly one utility and will never expand, one well-built integration is manageable. If you are a utility yourself, or a vendor to utilities, you are on the other side of the interface and the calculation is different. And if your competitive advantage genuinely lies in the raw ingestion layer rather than what you do with the data, owning it may be worth the cost. For most energy software, sustainability platforms, and property or facilities products, the advantage is in the analysis and the customer experience, not in maintaining sixty OAuth clients.
If you want to see what the single-interface path looks like against your own list of utilities, book a walkthrough at ezgb.ca. We will map your customers' utilities to the available connection methods and show you the delivered data shape before you commit engineering time.
How the aggregator path fits into your product
A typical integration has three parts. First, an authorization step your customer completes, either inside your app through an embeddable component or through a link. Second, a delivery method your backend consumes: a REST API for on-demand queries, or scheduled CSV or SFTP drops for batch systems. Third, your own mapping of delivered accounts and meters to the objects in your product. The connecting Green Button data to a CRM or custom app guide shows that mapping in practice.
The Green Button Alliance describes Connect My Data as covering electricity, natural gas, and water usage data, with usage summaries that carry billing details such as payments, generation and distribution charges, tariff name, demand charges, and third-party charges. An aggregator that preserves those fields lets you build cost analytics, not just consumption charts.
Frequently asked questions
Should I build my own utility data integration or use a utility API aggregator?
Count the utilities your customers touch today and in two years. If the answer is one, and it will stay one, a build is defensible. If the answer is more than a handful, an aggregator is almost always cheaper and faster, because the registration, OAuth, parsing, and maintenance work repeats for every utility and that work does not differentiate your product.
What is the easiest way to get customers' utility data via API across many utilities?
Use a single interface that already holds the utility relationships. Your customer authorizes once, through an embedded component or link, and your backend receives standardized data by REST API, CSV, or SFTP regardless of which utility served the account. For accounts with no digital feed, the same interface should accept PDF bills so that coverage does not stop at the utilities with Green Button.
Does an aggregator change who owns the data?
No. The data belongs to the customer, who authorizes its release. The customer can shorten or revoke the authorization, and the OEB notes they can do so by contacting their utility. Your product and the aggregator are both authorized recipients, not owners.
What happens for utilities that do not support Green Button?
Ontario's page on Green Button says it applies to most regulated Ontario electricity and natural gas utilities, which means some are exempt, and outside Ontario coverage varies. For those accounts, PDF bill digitization is the practical route. EZGB combines both so that a portfolio is not split across two systems.
How long does it take to go live with an aggregator?
The technical integration is typically short, because it is one API and one authorization flow. The longer pole is customer consent: each account has to be authorized by the customer of record, so plan the enrolment experience with the same care as the integration.
Sources
- Green Button Alliance: Green Button standards (ESPI, DMD, CMD, intervals)
- Green Button Alliance: Green Button Connect My Data (CMD)
- Green Button Alliance: 55 Ontario-based utilities' platforms certified (November 2023)
- Green Button Alliance: Ontario's electric and natural gas utilities to provide Green Button data (February 2022)
- Ontario Energy Board: Green Button
- Ontario.ca: Lower your energy bills with Green Button
- Toronto Hydro: Green Button and Third Party Terms for Green Button Connect My Data
- RFC 6749: The OAuth 2.0 Authorization Framework
- Hydro Ottawa: Green Button
Source: greenbuttonalliance.org