If you build software that needs other people's utility data, you have three options: ask users to upload files, build integrations yourself, or use an API that does the collection for you. Most teams reach the third option after trying the second, usually about four utilities in.
The problem with comparing utility data APIs is that every vendor's marketing page says the same four things: broad coverage, normalised data, simple authorisation, developer-friendly docs. Those claims are not differentiators because nobody claims the opposite. Below are the questions that do separate them, in roughly the order they will bite you.
1. How does the customer authorise access, and who owns that relationship?
This is the most important question and it is rarely first on anyone's evaluation list. Utility data belongs to the utility's customer, and somebody has to get that customer's permission. There are broadly three models.
| Model | How it works | What it costs you |
|---|---|---|
| Standards-based authorisation | The customer authorises at the utility's own portal, and the utility sends data directly | Cleanest consent trail. Limited to utilities that implement the standard |
| Credential-based collection | The customer hands over their utility login and the provider logs in as them | Broad coverage. The customer is sharing a password, which many enterprise customers will refuse |
| Manual or document-based | The customer forwards bills or uploads files | Works everywhere. Not a feed, and the effort recurs monthly |
The right answer depends on who your customer is. A residential app can often use credential-based collection without friction. A municipality, a hospital or a public-sector procurement will usually not permit password sharing at all, and the evaluation ends there regardless of coverage.
In Ontario specifically, standards-based authorisation is not optional for utilities: the province requires electricity and gas utilities to offer customers their own data in a standard format, which we cover in Ontario's Green Button regulation. That changes the calculus in this market compared to most of North America.
2. What exactly is in the payload?
"Utility data" covers at least four different things, and a provider may supply one and not the others.
- Interval consumption. Hourly or finer, which is what load analysis and demand work need.
- Billing data. The invoice totals, the charge lines, the rate class, the service period. This is what cost analysis needs and interval data cannot substitute for it.
- Account and premises metadata. Service address, meter identifiers, account status. Boring until you have a portfolio and need to match accounts to buildings.
- Tariff information. Almost never included, and it is what actually determines cost. Plan to source it separately.
Ask for a real sample payload for a real commercial account, not a sanitised example. The gap between the documentation and the production payload is where the surprises live. We compare the two main data shapes in interval data versus billing data.
3. What happens when a utility changes its portal?
Utilities redesign their customer portals without telling anybody, and every credential-based integration breaks the day they do. This is the recurring cost of the whole category, and it is the question that separates a product from a project.
- Who notices when a connection breaks: you, the provider, or your customer?
- How long does a fix typically take, and is there an SLA or just best effort?
- Does the provider backfill the data missed while the connection was down, or is there simply a hole?
- How are partial failures reported? A feed that silently returns nothing for one account out of two hundred is worse than one that errors loudly.
Ask for the incident history. A provider with real coverage has broken connections regularly, and one that claims otherwise either has very few utilities or is not counting.
4. How much history, and what happens to closed accounts?
Most evaluation happens on a live account with recent data, and most real work needs history. Two years is the usual minimum for anything involving a baseline or a year-on-year comparison.
- How far back does the provider fetch on first connection? Some pull everything the utility holds, some pull twelve months.
- What is available for an account that has since closed? Tenant turnover and building sales make this common, and losing the history of a site you still own is a real problem.
- Are estimated reads flagged, and are subsequent corrections delivered? A corrected read that arrives as a new value, with no indication it replaces an earlier one, will quietly double count.
- Is the raw utility payload retained, or only the provider's normalised version? Normalisation involves decisions, and you will eventually want to check one.
5. Normalisation: how much, and is it reversible?
Normalising across utilities is genuinely valuable and it is also where information gets lost. A provider that maps eleven different charge-line descriptions onto one canonical label has made your life easier and has thrown away the distinction. That is fine until you need to know whether a particular rider was applied.
The question to ask is whether the original is kept alongside the normalised version. If it is, normalisation is a convenience. If it is not, it is a lossy transformation you cannot audit.
"Ask whether you can get the raw utility payload. The answer tells you whether you are buying a data service or a data opinion."
6. Coverage, counted honestly
Coverage claims are the least comparable numbers in this category, because providers count differently. A list of utilities is not a list of working connections, and a utility that is technically supported for residential accounts may not be supported for commercial ones.
- Ask for coverage of your actual accounts, by utility and by account type, not a general count.
- Ask whether commercial and industrial accounts are supported, since these often live in a different portal from residential.
- Ask what the success rate is on first connection attempt for the utilities you care about.
- If your portfolio is concentrated in one province or state, a specialist with deep local coverage usually beats a continental provider with shallow coverage everywhere.
Our own view on the build-versus-buy decision, which is really a question about who carries the maintenance, is in utility data aggregator versus building your own integrations.
7. The commercial questions people forget
- Pricing unit. Per account, per connection, per call, or per site? A portfolio with many small accounts prices very differently under each.
- What happens to your data if you leave. Can you export the history you have accumulated, in a usable format, without a negotiation?
- Who is the data controller. For enterprise and public-sector customers this question will be asked by somebody in procurement and the answer needs to be written down already.
- Whether the provider will sign your customer's terms. A municipality's procurement process is not going to accept a click-through agreement.
A short evaluation script
Give every shortlisted provider the same five accounts from your own portfolio, including the messiest one, and ask for:
- A real payload for each, raw and normalised.
- The full available history for one of them.
- A closed or transferred account, if you have one.
- Their incident log for the utilities involved over the last twelve months.
- The authorisation flow as your customer would see it, end to end, on a phone.
That last item catches more problems than the rest combined. An authorisation flow that works fine on a desktop and strands a facility manager on a phone will fail in the field regardless of how good the data is. For the mechanics of the standards-based flow, see OAuth authorisation in Green Button Connect My Data.
The relevant standards documentation is published by the Green Button Alliance and the underlying data model by Green Button, and it is worth reading the specification once before evaluating anything, because it tells you which questions the standard already answers and which ones are each provider's own choice.
Frequently asked questions
What is the best utility data API?
There is no single answer, because the deciding factor is usually authorisation rather than data quality. If your customers are enterprise or public sector, a provider that requires utility passwords is likely to be rejected in procurement no matter how good the coverage is. If your accounts are concentrated in one region, a specialist usually beats a continental provider.
Should we build our own utility integrations or use an API?
The question is who carries the maintenance. Utilities change their portals without notice, and each change breaks an integration. Building two or three is straightforward; keeping thirty working is an ongoing engineering commitment that rarely differentiates your product.
Is there an API to get customer utility account data?
Yes, and in some jurisdictions the utilities are required to provide one. Ontario requires electricity and gas utilities to make customers' own data available in a standard machine-readable format, which means standards-based authorisation rather than credential sharing is available across the province.
Does a utility data API include the tariff?
Almost never. Most provide consumption and billing data but not the rate structure that produced the charge, which means cost analysis needs the tariff sourced separately. Check this early, because it is frequently assumed and rarely included.
How much history can we get on first connection?
It varies from twelve months to everything the utility holds. Ask specifically, because anything involving a baseline or a year-on-year comparison needs at least two years and retrofitting history later is often impossible.