Usage history that outlives the point-of-sale label

Connected washing machines, ovens and refrigerators already log cycle history, energy use and error codes to the manufacturer's cloud. The Data Act gives owners — and the independent repair technician they choose — a standing right to that data, long after the Energy Label at purchase stopped being relevant.

See what applies now Scope your appliance API

A label at purchase. A right that keeps going after.

The Data Act has applied generally since 12 September 2025. Ecodesign and Energy Label duties under the ESPR operate at the point of sale — a separate, earlier moment in the product's life.

Requirement	Status on review date	What it means for an appliance manufacturer
Owner access-on-request	Binding since 12 September 2025	Provide an authenticated request path for usage, energy and error data already logged
Owner-directed third-party sharing	Binding since 12 September 2025	Let an owner route their own appliance data to an independent repair technician
Pre-contract data transparency	Binding since 12 September 2025	Disclose what a new appliance records and how it can be exported, before purchase
Accessible by-design architecture	Applies to appliances placed after 12 September 2026	New appliance platforms should ship the access API as a core feature

Usually in scope

Usage and cycle history
Device state (door status, cycle phase, standby)
Energy and water consumption
Error and fault codes

Usually outside Chapter II

Proprietary cycle-optimization or predictive-maintenance model internals
Cross-household aggregate analytics used for product-development research
Firmware and embedded control logic
Data never captured or retained by the manufacturer's cloud

Field group	Typical source	Delivery format
Usage & cycle history	Appliance controller via app sync	Structured export per cycle, CSV/JSON
Device state	Sensor/controller status feed	Status API for current and recent state
Energy & water consumption	Onboard metering	Interval export per cycle or per period
Error/fault codes	Controller diagnostic log	Structured export with code, timestamp and severity

From an app-only view to a downloadable, shareable record

The manufacturer's app already displays this data to the owner. The access layer is what makes it exportable and shareable with an independent repair technician, not just viewable inside one app.

Today: a closed loop

Product

Smart appliance

Backend

Appliance manufacturer cloud

Usage/cycle history
Device state
Energy & water consumption
Error/fault codes

Only exit

Manufacturer's own app

No user-facing export or API
No route for the user to authorize a third party
No permissions model, so every request is a one-off exception
No audit trail if a user or regulator asks what was shared

With a Data Act access layer

Product

Smart appliance

Backend

Appliance manufacturer cloud

Usage/cycle history
Device state
Energy & water consumption
Error/fault codes

New layer

Data Act access layer

Field catalog
User & device entitlements
Consent & grant registry

Customer export & portal

CSV/JSON, self-service, same quality as the manufacturer sees

Third-party API (OAuth)

Purpose-bound grant to a repairer, analytics or energy provider

Audit & compliance log

Request, decision, recipient and delivery evidence for review

What we implement, concretely

Usage history, device state, energy consumption, error data and downloadable exports, plus third-party access and an audit layer.

Capability	What it does
Usage & consumption API	Authenticated access to cycle history, device state and consumption per appliance
Downloadable data export	Self-service CSV/JSON export for the owner's own records
Third-party access for repair technicians	Purpose-bound, revocable credentials for an independent repair provider
Entitlement & audit layer	Tenant/landlord-aware access control with a reviewable decision log

Trace the appliance-cloud pipeline

Map every field from controller through app backend to storage, and classify raw vs. derived.

Model tenant/landlord entitlements

Decide who the practical user is in rented or furnished properties, and how access transfers.

Design the owner API

Define catalog, request, third-party grant and delivery endpoints separate from the internal app API.

Build the decision engine

Turn catalog, entitlement and privacy checks into explainable allow, partial and refuse outcomes.

Ship export and sharing

Deliver an owner export and a repair-technician sharing flow with revocable credentials.

Test the edge cases

Run through multi-appliance hubs, tenant move-out and disputed cycle-optimization requests.

Smart appliance Data Act FAQ

How is this different from the Energy Label shown at point of sale?

The Energy Label, driven by Ecodesign rules under the ESPR, discloses standardized efficiency information at the point of purchase — a snapshot, set once for the model. The Data Act is a separate, ongoing right for the owner to access their specific unit's actual operational history after purchase: real cycle-by-cycle usage, energy consumption and faults, not a pre-purchase estimate.

Is an independent repair technician an eligible third party for fault-code data?

Yes, under Article 5, provided the owner is the one directing the sharing and the recipient isn't a Digital Markets Act gatekeeper. This is one of the more common use cases for appliance data — an independent technician diagnosing a fault without needing the manufacturer's own proprietary diagnostic tool.

Are cycle-optimization algorithms trade secrets?

The algorithm itself can be, through the Act's structured trade-secret process. The cycle history, energy and water consumption, and error codes it produces are a different matter — those are the operational data the owner is entitled to regardless of how proprietary the underlying optimization logic is.

How do appliances in rented or furnished properties handle tenant vs. landlord entitlement?

Generally the occupying tenant is the practical user during the tenancy, since they're the one generating and benefiting from the usage data, with the landlord's interest more naturally tied to the appliance itself than to the tenant's specific usage patterns. Model this explicitly rather than defaulting to whoever registered the appliance account.

Must historical usage data going back to purchase be exportable in bulk?

Where it's readily available and relevant to the request, yes — an owner requesting their full usage history has a legitimate claim to what the manufacturer's cloud already retains, not just the most recent cycles. Retention policy, not the request itself, is what actually limits how far back an export can reach.

Does a smart-appliance hub that aggregates several appliances complicate who the data holder is?

It can. If a hub or gateway ingests data from appliances made by several manufacturers and presents a unified view, the hub operator becomes a practical data holder for that aggregated view, separate from each appliance manufacturer's own data-holder role for their individual unit's raw data. Both relationships need their own pre-contract disclosure and access-request handling.

Primary sources and status

Reviewed 9 September 2026. The Data Act, GDPR and ESPR are binding EU regulations. The Commission FAQs are non-binding implementation guidance. Yarify's API contract, entitlement model and delivery sequence are engineering recommendations, not legal advice.