From feedback to functionality: Advancing the eSett API

As part of our ongoing eSett API development, we hosted a customer workshop on the 14th of May 2025 to gather direct input from our stakeholders. This interactive session offered valuable insights that will help shape the direction of the project as we continue moving from concept to implementation.

For background information on the project, including our objectives and timeline, visit our dedicated API project page: https://www.esett.com/esett-api/

For detailed information the workshop notes, visit our customer committee page: https://www.esett.com/customers/customer-committee/

Listening to the customers: Why this workshop mattered

The workshop was kicked off by Ville Rahkonen, who outlined the session agenda: an overview of the API project, key takeaways from our customer questionnaire, and group discussions on key design topics. Rami Ayoub presented a summary of the project’s background and objectives. He highlighted that the API initiative is built on long-standing customer feedback and driven by the need to modernize our customer data exchange. The ongoing settlement system back-office renewal provides the ideal opportunity to transition away from the legacy SOAP-based Information Service and toward a more flexible REST API architecture. 

One of the project’s core design principles is to decouple the API from the core system, which enables more agile feature delivery and clearer, more accessible data structures. While timelines are still indicative, our goal is to deliver an initial testable version in early 2026, replicating current Information Service capabilities in a modernized format — with continuous development based on customer input. 

Tuomas Pulkkinen presented findings from our earlier customer survey (arranged in April 2025). The feedback emphasized a clear preference for breadth of data access over extensive time aggregation. For example, respondents favored access to 15-minute resolution data for 10–20 critical data types over having a wide range of aggregations. 

There was also expressed interest in future bidirectional API capabilities, particularly from Balance Responsible Parties (BRPs) and Balancing Service Providers (BSPs), though this is not seen as an immediate priority.

Workshop discussions: Insights and ideas 

Project plan feedback

Customers welcomed the phased rollout strategy, emphasizing the importance of avoiding breaking changes once functionality is live. Participants supported the initial focus areas — starting from Information service scope and considering 2-way solution for bilateral trades after that — and stressed the need for clear documentation (e.g., Swagger) and effective communication to support vendors and internal developers. 

Identification code preferences

Market participants generally preferred using codes for Market Party, Production Unit, Regulation Object or area instead of MEC ID (a technical timeseries ID) when fetching data. MEC ID was seen as less intuitive and potentially unstable. Ideally, the API should support multiple ID types with the ability to track historical changes if MEC ID is used. 

Data history requirements

There was broad agreement that data should be available for at least three months, with many suggesting access for up to three years to allow for corrections and audits. 

Data prioritization

Most critical: imbalance settlement data, prices, and trading information.
Also important: production and consumption data (especially in markets without a centralized datahub).
Lower priority: administrative data like bank details.
Participants also noted the importance of clearly stated measurement units (e.g., MW vs. MWh). 

Testing expectations 

Early access to a stable test environment with production-like data was a recurring theme. Participants encouraged involving system vendors early and providing clear communication on testing schedules, supported by active Q&A channels and responsive support. 

Risk awareness and mitigation 

Top concerns included data security, limited data availability, and insufficient communication. Suggestions included thorough access controls, transparent documentation, responsive customer support and proactive updates to minimize disruption and confusion. 

Long-term vision 

The ideal vision includes making all relevant data available via a bi-directional API, allowing market parties to filter and retrieve data by their role and market party code. Some envision fully replacing current data packages with APIs. Incremental and early delivery, with early feedback loops, was seen as essential to success. 

What happens next? 

We’re truly grateful for the input shared during the workshop. Many of the ideas and preferences expressed by participants are already being incorporated into our design decisions and development roadmap. For instance, we are: 

• Preferring breadth of data access over extensive time aggregation 

• Prioritizing support for user friendly identification types 

• Reviewing how to offer long enough historical data access 

• Refining documentation and planning clear communication flows for testing 

As we continue development, we will keep engaging with our customers and sharing updates on progress. Your input helps ensure the API not only meets today’s needs but is built to evolve alongside the energy market. For the latest project timeline, please refer to our project page: https://www.esett.com/esett-api/ 

Stay tuned — and thank you for shaping the future of data exchange with eSett.