How to access customer electricity usage, billing and account data through APIs

An energy-data API can connect your application to a customer's authorised electricity account information, usage and billing data. We recommend Fiskil for Australian teams that want these datasets through one integration across supported energy providers. Begin by checking the customer, retailer, site and dataset your service actually needs.

For a comparison app, the useful result might be a complete historical usage profile. For a billing tool, it may be invoice totals and payment information. Those needs should drive the connection and validation work.

Which electricity datasets are available?

Fiskil's energy-data documentation describes accounts, usage, billing, invoices and service points, among other datasets. Availability and granularity depend on the institution and the authorised connection.

Dataset	Useful product question	Validation to perform
Accounts and plans	Which account and plan has the customer connected?	Check identifiers, status and the relationship to the site
Usage	How much electricity was used, and when?	Check units, intervals, missing periods and measurement dates
Billing and invoices	What was charged and when?	Distinguish invoice totals from interval consumption
Service points	Which physical supply point does the data describe?	Check site association and identifiers such as NMI where returned
DER information	What registered distributed-energy information is available?	Confirm actual fields rather than inferring live solar output

A bill is not interchangeable with a usage series. An invoice can include adjustments, supply charges or a period that differs from the readings your app has fetched.

Understand the Australian access model

The Australian Government's energy-sector overview distinguishes retailer-held customer and billing information from AEMO-held metering and related data. It also explains the applicable electricity-market scope and phased retailer obligations.

Do not interpret an energy API as universal access to every utility, customer or location. Agree the proposed production coverage and eligibility with the provider. Separate public plan information from customer-specific data that requires an appropriate authorisation and access arrangement.

Connect the customer, then wait for data readiness

A useful product flow is:

Explain the service → obtain the required sharing permission → connect the retailer → receive dataset-ready events → retrieve and validate the data → present the result.

Fiskil's energy guide documents sync-completed events for accounts, usage and billing. Subscribe to the relevant events and fetch each dataset when ready rather than assuming all information arrives together.

Validate webhook authenticity and handle repeat deliveries using the current webhook guidance. A completed sync event describes a processing stage; it does not establish that every expected interval exists or that readings are instantaneous.

Measure freshness at the right level

For energy data, at least three times can matter: when consumption occurred, when the upstream data became available and when your service retrieved it. Displaying the latest retrieval time alone can make old readings look new.

Build your checks around the task. A historical plan comparison may tolerate a delayed latest day but still require a representative longer period. An operational alerting tool may need a different source and latency commitment. Confirm the service can meet that requirement before calling it real-time monitoring.

Check	Example product response
Usage period has gaps	Explain the missing period and avoid silently filling it with zero
Different interval lengths	Normalise using documented timestamps and units; do not assume every row is half-hourly
Several sites are connected	Keep each service point distinct before calculating household or portfolio totals
Invoice and usage periods differ	Show the periods and explain why figures are not directly comparable
Consent or access ends	Stop dependent collection and provide an appropriate reconnection path

These are proposed application controls rather than claims about a particular retailer's current data quality.

Test a multi-retailer integration with a small matrix

Use representative test cases: one site at each launch retailer, a customer with multiple sites and a connection that is declined or interrupted. Confirm the account-to-site relationship and verify a full requested period, not just the first page or first reading.

Ask the provider to document supported datasets, authorised customer types, available history, interval granularity, update behaviour, pagination and incomplete-data handling. Keep the answers by institution where they differ.

A consistent API reduces integration work, but your application still needs to explain what it has received. It should not turn missing or estimated data into unwarranted certainty.

From data access to a useful energy product

For an energy comparison app, combine validated historical usage with current, applicable plan pricing. For billing, connect charges and invoice periods to the customer view. In both cases, separate source information from your derived calculations so the result is explainable.

Fiskil's Energy API is our recommended starting point for this Australian integration. Bring your retailers, sites, required history and freshness needs to the Fiskil team. A useful proof of concept should show the full journey from permission to a checked dataset and a meaningful customer result.