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". What developers usually mean is a publicly documented REST API that returns consumption data as JSON after authentication. Austria organizes that access differently.

The ElWG requires grid operators to provide meter data through a programmatic interface and a web portal. For eligible third parties, the standardized market process runs through EDA and consent for each metering point.^[1] This article explains how that access works, what a smart meter interface in Austria needs to cover, and how to retrieve the data through a single REST API.

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

A publicly documented REST API in the usual developer format is not the standardized access route. Section 58 ElWG refers to programmatic interfaces operated by grid operators, but it does not prescribe a public REST endpoint using Bearer tokens and JSON responses.^[1]

The market role also matters when searching for an "EVN Smart Meter API": Netz Niederösterreich is the grid operator for smart meter data in EVN's network area. EVN Energievertrieb is the electricity supplier.

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. EDA itself is neither a central database nor a single REST endpoint.

EDA lists three connection types for energy service providers:^[2]

• The EDA Portal, with an integrated process environment for sending and processing messages.
• An email connection, which requires your own software application.
• A dedicated communication endpoint, which requires your own IT environment and software application.

The integration task therefore lies in market communication: processing EDA messages, managing consent, and normalizing readings. 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

Before an eligible third party receives meter data, the meter holder must permit the transfer. Section 60 ElWG governs that permission and the right to revoke it at any time.^[1]

In the online process, 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 consent in the 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. An offline process also exists, in which consent is obtained outside the portal and demonstrated to the grid operator.

Consent is valid for the period defined in the request and can be revoked at any time. Historical readings can be requested for up to three years into the past.^[3] For the API this means: your software triggers the consent process, while in the online process 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 central calls show the basic flow:

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

Further endpoints cover status queries and revocation. XML parsing, running specialist software, and writing your own message handlers fall away from your application. Consent and data delivery remain asynchronous processes.

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"

The API returns the readings supplied by the grid operator at the finest available resolution. With quarter-hour reading active, that means 96 values per day. Ongoing delivery follows the T-1 principle: the previous day's values are supplied the following day. Later corrections are captured during the next synchronization through the sync cursor. Responses also include 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.

Ongoing maintenance continues after launch. 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?

The ElWG requires grid operators to provide a programmatic interface and a web portal. For eligible third parties, the standardized market process is organized through EDA. A service such as energiedaten.at provides one REST API in the usual developer format across all grid operators.

Can I read my own smart meter data via API?

As an end customer, you can access your meter data through your grid operator's programmatic interface and web portal. For a consistent integration across multiple grid operators, you can use a service that delivers the data via REST API after consent. Registered market participants can establish their own EDA connection.

Do I need a separate consent for each meter?

Yes. Consent applies per metering point. In the online process, the respective meter holder confirms it in the 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?

Ongoing data delivery follows the T-1 principle. The previous day's values are supplied the following day at the finest resolution available for the metering point.

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 correction appears during the next synchronization through the sync cursor.

From search to integration

Anyone searching for a "Smart Meter API" is looking for reliable, programmatic access to consumption data. The Austrian market process for that access runs through EDA. energiedaten.at translates that process into 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] Elektrizitätswirtschaftsgesetz (ElWG), BGBl. I No. 91/2025, Section 58: meter data through a programmatic interface and web portal; Section 60: permission and revocation of meter-data transfers to eligible third parties.

[2] EDA Energiewirtschaftlicher Datenaustausch GmbH, "Energy service providers": EDA Portal, email connection, and communication endpoint as connection types.

[3] ebUtilities, "Request energy data" process: historical requests are limited to a maximum of three years into the past.