Smart meter data via API in Austria

You want to pull a smart meter's consumption data into your own software: programmatically, refreshed every day, rather than having someone export a file. The obvious search is then "Wiener Netze Smart Meter API" or "EVN Smart Meter API". The answer surprises many developers: no such API exists at the individual grid operators.

Programmatic access to smart meter data in Austria works along a different path. This article shows why there is no per-operator API, what a smart meter interface in Austria needs to cover, and how you retrieve the data through a single REST API.

Is there a Smart Meter API from Wiener Netze or EVN?

The short answer is no, at least not in the form you would expect from a modern web API. Neither Wiener Netze nor EVN nor any of the more than 140 Austrian distribution grid operators offers a public REST API that you call to get consumption values back as JSON.^[1]

The reason lies in how the Austrian electricity market is structured. Grid operators store the measurement data and make it available through a regulated shared infrastructure, the EDA network. EDA stands for Energiewirtschaftlicher Datenaustausch (energy data exchange), and it works as a decentralized messaging system. Market participants exchange encrypted XML messages following an industry-specific standard. There is no central database and no single endpoint for an application to call.

There are three ways to connect, and none of them is a ready-made API:

• The EDA user portal, a web interface for manual queries. Functional, but not designed for programmatic processing.
• An email connection for market participants with their own software, suitable for a limited number of metering points.
• A dedicated communication endpoint for larger volumes: specialized software you install and maintain yourself.

Anyone who wants to integrate smart meter data into an application therefore faces a task that has little to do with "calling an API". We trace the full path from meter to your system, station by station, in the data journey.

What a smart meter interface in Austria needs to cover

Before you pick one of these routes, look at what such an interface has to deliver. Three requirements decide whether you can work with the data:

• One connection for every grid operator. A good interface bundles all distribution grid operators into a single connection, so you don't maintain a separate integration per operator.
• Prepared data instead of raw data. One consistent format across all grid operators, with documented fields, ready for your software to process.
• Traceable quality. Readings carry quality levels, and some are corrected later. If that isn't visible, you are working with numbers whose reliability you can't judge.

On top of that come the meter holder's consent, current values on a T-1 cadence, and delivery that fits your architecture. All three are covered in detail further down.

Consent comes before the data

Regardless of the technical route, one rule holds without exception: before any data flows, the meter holder must give consent. The process is regulated by law and GDPR-compliant.^[2]

An authorized service provider submits a data request for a specific metering point via the EDA network. The responsible grid operator validates it. The meter holder then confirms the consent in their grid operator's web portal. This step cannot be automated, because it requires a deliberate decision by the meter holder. Only then does data delivery begin.

Consent is valid for a defined period of up to three years and can be revoked at any time. For the API this means: your software triggers the consent process, while the confirmation itself comes from the customer via their grid operator. Build this intermediate step firmly into your onboarding flow.

One REST API for every grid operator

energiedaten.at covers exactly these requirements. Instead of building your own EDA integration and normalizing each operator's data format, you talk to a single REST API. The platform takes over the EDA communication, the preparation of the raw data, and the quality checks. What arrives at your end is consumption data your software can process directly.

Three calls cover the entire lifecycle of a metering point:

POST /api/v1/smart-meters                  → register a meter
POST /api/v1/smart-meters/{id}/consent     → start the consent process
GET  /api/v1/smart-meters/{id}/data        → retrieve consumption data

XML parsing, running specialist software, and writing your own message handlers all fall away. Your first data is only a handful of lines of code away.

How to access the data via API

Authentication uses a Bearer token with defined scopes such as data:read or consents:request, so you can keep access tightly limited per integration. Retrieving the consumption data for a metering point then looks like this:

curl https://energiedaten.at/api/v1/smart-meters/{id}/data \
  -H "Authorization: Bearer $API_KEY"

Back comes JSON at quarter-hour resolution, delivered on a T-1 basis: a day's values are available the following day. For ongoing synchronization the responses carry a sync cursor, alongside standard rate-limit headers. The full reference, with every endpoint, scope, and response field, lives in the API documentation; a guided way in is on the developer page.

Pull the data or have it pushed

The REST API is the pull route: you request data when you need it. For many integrations the push route is more practical, where data arrives at your end as soon as it comes in. There are further channels for that:

• Webhooks notify your system as soon as new values are available.
• MQTT suits IoT and streaming applications.
• CSV via email delivers files to a mailbox your systems pick up.
• SFTP provides files for ERP integration.

The REST API is included in every plan. Which push channels are added depends on the plan you choose; the details are on the pricing page.

Prefer ready-made exports to writing code? Our reporting route delivers consumption data straight into your spreadsheet or reporting tool.

What you don't have to build yourself

Building your own EDA integration is feasible, but it is a project in its own right. Registration as a market participant, a dedicated communication endpoint with licensed specialist software, consent management per metering point, parsing and transforming the XML messages, quality monitoring of the readings, efficient time-series storage, and several delivery channels each with their own error handling. On top of that come the biannual protocol updates from the EDA network that you have to keep up with.

In practice, building it takes several months, after which ongoing maintenance begins. For businesses whose core product is not EDA infrastructure, that effort quickly outweighs the benefit. How energiedaten.at takes on this task for software products and for energy service providers is described on the pages for developers and energy service providers.

Frequently asked questions

Is there an official Smart Meter API from Wiener Netze or EVN?

No. Grid operators make their data available through the regulated EDA network, not through a public web API. You get a REST API spanning all grid operators through a service like energiedaten.at.

Can I read my own smart meter data via API?

Access through EDA can only be set up by registered market participants. As an individual or a business, you reach your values either through your grid operator's portal or through a service that delivers the data via API once you have given consent.

Do I need a separate consent for each meter?

Yes. Consent applies per metering point and is confirmed by the respective meter holder in their grid operator's portal. The API triggers the consent process; the confirmation itself stays with the customer.

How current is the data through the API?

The data arrives on a T-1 basis. A day's consumption values are available the following day at quarter-hour resolution.

What do the quality levels in the readings mean?

Each value carries a quality level: L1 (measured) and L2 (reliable substitute) are considered final, L3 is preliminary. When a grid operator replaces an L3 value with better data, the API carries the correction into the change stream.

From search to integration

Anyone searching for a "Smart Meter API" is really looking for reliable, programmatic access to consumption data. It exists in Austria. It is provided through a layer that consolidates the EDA network behind a single REST API. For the wider context, see our guide to smart meter data in Austria, and when manual data collection reaches its limits is covered in the article on automation.

If you want to bring consumption data into your product, take a look at the plans or start on the page for developers.

[1] E-Control, Smart Meter Monitoring Report 2025 (October 2025): more than 140 distribution grid operators in Austria in total.

[2] Elektrizitätswirtschaftsgesetz (ElWG), BGBl. I Nr. 91/2025, § 58: data access for authorised third parties requires the customer's consent; after consent, the data is transmitted at the finest available resolution.