Every energy software product eventually hits the same wall. The features are compelling, the model is sound, and then the roadmap stalls on a single dependency: getting real utility data in, reliably, for every customer, from every utility they happen to use. Teams that try to solve this by scraping utility portals learn a hard lesson. The data plumbing quietly becomes the product, and it is the least differentiated part of the whole thing.
This guide is for integrators and software teams weighing how to source utility data for their own applications. It explains why a utility data API beats scraping, what flexible delivery looks like, why standardized formats matter across utilities, how embeddable components shorten the build, and why data ownership should shape the decision. The frame is Ontario, where EZGB provides this across more than fifty-five utilities.
Why Not Just Scrape Portals
Scraping utility portals is tempting because it looks like a shortcut. In practice it becomes a maintenance burden that never ends. The reasons are structural, not a matter of engineering skill.
- Portals change. A layout update or a login change can break a scraper without warning, and the break shows up as missing customer data.
- It multiplies with every utility. Each provider is a separate portal with its own quirks, so the work grows with every utility your customers use.
- Credentials are a liability. Storing and handling customer logins raises security and trust questions you would rather not own.
- It sidesteps authorization. The clean path is data the customer has authorized to be shared, not data pulled by imitating a login.
- It does not scale. Every new customer and every utility change adds to a backlog of scraper upkeep that competes with real product work.
The deeper issue is opportunity cost. Time spent nursing scrapers is time not spent on the features that make your product worth buying. Data acquisition is essential, but it is not where a software team wins.
Build or buy: what each path actually costs
Teams evaluating this usually frame it as a build versus buy decision, and the honest answer depends on how many utilities you need and whether the data is your product or an input to it. The table below is the comparison we would want to see if we were on the other side of it. A longer treatment of the same question is in utility data aggregator or building your own integrations.
| Build it yourself | Use a utility data API | |
|---|---|---|
| Per-utility onboarding | Register, obtain credentials and test with each distributor separately | One integration, with coverage added as utilities are onboarded |
| Customer authorization | You build and maintain the consent flow, and the revocation path, per utility | Handled as part of the service |
| Formats | ESPI XML plus per-utility CSV variants, unit and timezone edge cases | One delivery shape across utilities |
| Failures | Portal changes, expired authorizations and outages reach your on-call rotation | Absorbed upstream, with retries and monitoring |
| Time to first data | Weeks to months, depending on the number of utilities | Days |
| Ongoing cost | Engineering time that recurs whenever a utility changes something | A predictable line item |
| Where it fits | One or two utilities, stable scope, and the integration itself is your differentiator | Many utilities, or the data is an input to the product you actually sell |
Building is the right call more often than vendors admit. If your product serves a single utility territory and that connection is the core of what you sell, owning it end to end is defensible. The calculation changes at the third or fourth utility, when the work stops being an integration project and becomes an operations commitment that never ends.
Questions to ask any provider, including us
- Which utilities are covered today, and what happens when we need one that is not on the list? Our current coverage is on the supported utilities page.
- Who owns the customer authorization, and what does the customer see when they grant and revoke it?
- What is delivered when a utility is down or an authorization lapses: an error, a gap, or silence?
- Is historical data backfilled on connection, and how far back?
- What formats and delivery methods are available, and can we change later without re-onboarding accounts?
- How is the data corrected when a utility restates a reading after the fact?
- What are the commercial terms as account volume grows? Ours are on the pricing page.
Building on a Utility Data API Instead
A utility data API turns collection into a dependency you consume rather than a system you maintain. Your product asks for data through a stable interface and receives it in a known shape. The messy work of connecting to many utilities, handling authorized Green Button access, digitizing bills and normalizing formats happens behind that interface, so your team does not carry it.
This is the same reasoning teams already apply to payments, messaging and mapping. You would not build a payments network to charge a card. Utility data is the same kind of problem: a hard, shared piece of infrastructure that is better consumed through a clean interface than rebuilt in-house. Building on an API lets your roadmap move at the speed of your features rather than the speed of portal maintenance.
Flexible Delivery: JSON, CSV, REST and SFTP
Software teams integrate in different ways, and the right data source meets you where your architecture already is rather than forcing a single pattern.
- A REST API for real-time or on-demand access, so your application requests data when it needs it and gets a predictable response.
- JSON for straightforward parsing into modern services and front ends.
- CSV for pipelines, analytics jobs and bulk processing.
- SFTP for scheduled batch drops when you prefer files landing in a known location on a cadence.
The value of offering several delivery methods is that you do not bend your system to the data source. Whether you are event-driven, batch-oriented or a mix, the same underlying data reaches you through the channel that suits your design.
Standardized Formats Across Utilities
The single most useful thing a utility data API gives a software team is uniformity. Ontario has more than fifty-five utilities, and even with the Green Button standard in place, raw data still varies in interval, in layout and, for bills, in structure and line-item naming. If that variation reaches your code, you end up writing per-utility special cases that multiply as you grow.
A good data layer absorbs that variation and hands you one consistent schema. A meter reading from one utility looks like a meter reading from another. A billed charge is labelled the same way regardless of which utility issued the bill. Your application logic is written once against a stable format, not many times against many formats. That is what keeps a growing integration from turning into a growing pile of exceptions.
Embeddable Components
Beyond raw data, there is the customer-facing side of getting connected. Someone has to authorize access, and building the flows for that from scratch is its own project. Embeddable components let you place ready-made connection and authorization experiences directly into your product, so a customer can link their utility data without you designing and maintaining that flow yourself.
For a software team, this shortens time to launch. The authorization step, which is easy to underestimate, comes as something you drop in rather than something you build. Your team stays focused on the features that make your product distinct, while the connection experience is handled by components made for the purpose.
Data Ownership
Underneath all of this is a principle worth keeping in view: the data belongs to the customer. The clean way to obtain it is through their authorization, which is exactly what Green Button's Connect My Data is built around and what Ontario's regulation put in place across its utilities. Building on authorized access means your product rests on consent rather than on workarounds.
That matters for more than compliance. It matters for the trust your customers place in your product, and it matters when a customer wants to grant or withdraw access on their own terms. A data source built on authorization respects that ownership by design, which is a far stronger footing than data pulled by imitating a login.
How EZGB Serves Software Teams
EZGB, the Easy Green Button Connector from Screaming Power and built on MartinAI, is designed to be the utility data layer under your product. It collects consumption, usage and billing data through authorized utility connections and Green Button, digitizes billed charges with BillScan, and retrieves data on an ongoing automated basis. It delivers through a REST API, JSON and CSV, and SFTP, offers embeddable components for the connection experience, and normalizes formats so your code sees one consistent schema across Ontario's utilities.
The result is that your team builds on utility data instead of building utility data collection. The hardest, least differentiated part of the problem is handled, and your roadmap moves at the pace of the features your customers actually care about.
Get Started
If utility data plumbing is blocking your roadmap, EZGB is built to be the layer you build on instead. Visit the EZGB site to see the API, delivery options and embeddable components, review the pricing and signup pages to find the fit for your product, and book a walkthrough to see standardized Ontario utility data flowing into your application. Start building on clean, authorized utility data, and keep your team focused on the product only you can build.
Sources
- Green Button Alliance, Green Button Connect My Data: https://www.greenbuttonalliance.org/green-button-connect-my-data-cmd
- Green Button, Connect My Data: https://www.greenbuttondata.org/cmd.html
- Green Button Alliance, 55 Ontario-based Utilities' Platforms Are Now Green Button Certified: https://www.greenbuttonalliance.org/news/green-button-alliance-announces-55-ontario-based-utilities-platforms-are-now-green-button-certified
Source: greenbuttonalliance.org