API Web Services for the Future of Market Communication

In the energy industry, the term API is ubiquitous and is becoming mandatory for the transmission of market location. APIs are seen as a key technology for the market communication in order to optimize the exchange between market participants and to improve the EDIFACT standard. But what exactly is an API and how does it work?

In the energy industry, there is no appointment or product presentation that can do without the term API. In market communication, the API web service is used from 06.06.2025 for, among other things, the process for determining the MaLo ID of the market location is mandatory. The aim of this process is to provide the energy supplier with the necessary information for a delivery from the grid operator. Other market communication processes should follow this example.

The requirement is that API will increasingly replace EDIFACT. Until the introduction of the MaBiS hub is the express wish of the BDEW and the BNetzA to use API technology for communication between the market roles, metering point operator (MSB), supplier (LF) and network operator (NB). It is precisely from this point of view that it is crucial for success to convey the same basic understanding of this future technology API to all market participants.

An API (Application Programming interface) - or programming interface - is a collection of rules and protocols that enable software applications to interact with each other and exchange data, functions and functionalities.

APIs consist of various definitions and protocols that are used to develop and integrate application software. They serve as an interface that enables independent applications to communicate with each other and exchange information. API is therefore an interface technology that can be used to establish synchronous communication with defined start and end points.

The API communication works like a dialog between a client and a server. The client sends a structured request and the server responds with an equally structured answer. The API acts as an intermediary that enables interaction between the two. This dialogue must be standardized so that it is used in the same way by all participants.

The API guideline can be understood as the ultimate set of rules. The EDI@Energy API guideline for web APIs is like a set of golden design principles that ensure everyone has the best experience with web-based APIs. These guidelines create an API landscape that is so consistent and intuitive that both providers and users of web APIs can master it in no time.

In general, APIs and the associated guidelines help to ensure consistent and efficient use of APIs within the company and facilitate collaboration between different teams. Classic examples of companies that use their own APIs are Adidas, Zalando, Google or Otto.

In the world of API guidelines, there are some important rules to ensure that everything runs smoothly. These rules concern consistency, versioning, data types and JSON standardization, the components of each API web service, HTTP status codes, response codes, objects and the notification of changes. Some of these specifications are, for example:

• Change management

  Versioning is about ensuring that only compatible changes are made. This means that no new mandatory fields can be introduced that could damage the overall construct. Bug fixes are permitted, but only if they make the construct more stable. For example, the introduction of a new mandatory field is not permitted.

• Consultation documents

  Changes will be published in an official communication from the BNetzA's Ruling Chambers 6 and 7. This notice sets out the new rules and when they will apply.

• Downward compatibility

  A change is compatible if established API versions can still be used. One example is the addition of an optional parameter. The API provider must ensure that everything works smoothly, even if previous versions do not use this parameter. In contrast, upward compatibility is not supported.

• Data types and JSON standardization

  These are clearly defined to ensure that all data is in the same format. It's like a standardized language that everyone understands.

• Components of an API web service

  Important fields such as "TransactionID" and "creationTime" are mandatory to ensure idempotency. This means that if an operation is executed several times, it always delivers the same result and does not change the state of the system. It is like a trick that always works the same, no matter how often it is performed.

The authentication authority in the form of a SubCA and the directory service is crucial for communication. The role of the directory service is performed by decentralized providers.

Pre-condition

1. Market participant A (e.g. NB) requests its own EMT.API certificate via CSR from a SubCA.

2. The SubCA transmits the issued EMT.API certificate to market participant A (NB) and stores it in its LDAP directory.

3. The market partner (LF) stores its API endpoints for market communication in its API directory service.

4. If the LF does not yet have an EMT.API certificate of market participant A (NB), it queries this via the LDAP directory of the SubCA.

   • The LF sends a request for the EMT.API certificate of a market partner ID to the SubCA via the LDAP directory

   • The SubCA uses the market partner ID to determine the associated EMT.API certificate triple to the LF

Start the process of determining the MaLo ID

1. The LF reads the URL to the API directory service of the NB from the EMT.API certificate

2. The API endpoint is queried from the directory service for the market process

3. Now the LF is able to communicate with the NB via API web service

The communication only works if both (LF & NB) have SM-PKI certificates.