API-Webdienste als zweiter Übertragungsweg der Marktkommunikation

Kurzantwort

API-Webdienste sind der zweite Übertragungsweg der Marktkommunikation neben EDIFACT über AS4. Der Aufruf ist ein HTTP-Request mit JSON im Body. Die Antwort kommt zweistufig: Zuerst bestätigt der Empfänger mit dem Statuscode 202 nur den technischen Eingang, die fachliche Rückmeldung folgt als eigener Aufruf in Gegenrichtung.

Stand 05.10.2026 laufen genau zwei Prozessgruppen über API: die Ermittlung der MaLo-ID (GPKE Teil 2) und der Steuerbefehl an den Messstellenbetreiber (GPKE Teil 3). Alles Weitere, etwa ein API-Weg für Lokationsbündel oder die Kommunikation mit dem MaBiS-Hub, ist nach Mitteilung Nr. 58 der Bundesnetzagentur vom 01.10.2026 nicht vorgesehen. Der Lieferantenwechsel in 24 Stunden selbst läuft weiter per UTILMD über AS4.

Welche Prozesse heute über API laufen

Den Übertragungsweg legt die Spalte „Übertragungsweg“ der Anwendungsübersicht der Prüfidentifikatoren 4.0 (Stand 01.04.2026) fest. Sie führt AS4 oder API; bei API steht zusätzlich eine API-Kennung in einer eigenen Spalte. Die Auswertung der Fassung 4.0 ergibt drei Kennungen:

• API00003, MaLo-Ident (GPKE Teil 2): Prüfidentifikatoren 20000 (Anfrage des Lieferanten an den Netzbetreiber), 20010 und 20020 (negative und positive Rückmeldung). Die GPKE-Lesefassung schreibt für diesen Use-Case vor: „Dieser Use-Case ist über API-Webdienste zu realisieren.“
• API00001, Steuerbefehl (GPKE Teil 3): Anweisung des Netzbetreibers oder Bestellung des Lieferanten beim Messstellenbetreiber, dazu vorläufige und endgültige Antworten (Prüfidentifikatoren ab 23330).
• API00002, Information zum Steuerbefehl: der Messstellenbetreiber informiert Lieferant, weiteren Messstellenbetreiber oder Übertragungsnetzbetreiber.

Der Grund steht im Beschluss BK6-22-128: Die Kammer legt dort für den Steuerbefehl einen API-Webdienst fest, weil das Datenformat EDIFACT für diese Übertragung im Sekundenbereich nicht ausgelegt ist (BK6-22-128, Beschluss vom 21.11.2022). Wie sich der Netzbetreiber-Steuerbefehl ins Messwesen einfügt, erklären Steuerung und § 14a EnWG und die Prozessseite im Ablaufatlas.

Was geplant war und zurückgezogen wurde

Die Bundesnetzagentur hatte im September 2025 ein Konzept zur Nutzung und Veröffentlichung von API-Webdiensten zur Konsultation gestellt (Mitteilung Nr. 53). Ein Release 2.0.0 mit weiteren Diensten, etwa für Lokationsbündel und Berechnungsformeln, stand im Februar und im Juli 2026 zur Konsultation. Eingeführt wird es nicht:

• Mitteilung Nr. 56 (01.04.2026) veröffentlichte die API-Guideline 1.0b, ließ aber das Release 2.0.0 ausdrücklich außen vor.
• Mitteilung Nr. 58 (01.10.2026): Im Verfahren MaBiS-Hub (BK6-24-210-1) ist kein weiterer Ausbau zusätzlicher API-Webdienste vorgesehen. Bestehende Anwendungsfälle bleiben in EDIFACT, neue Fälle aus dem MaBiS-Hub werden ebenfalls in EDIFACT ausgeprägt. Die neu konsultierten Dienste werden nicht eingeführt, die UTILTS bleibt erhalten. Die API-Webdienste bleiben „voraussichtlich bis auf weiteres“ auf MaLo-Ident und Steuern beschränkt (Mitteilung Nr. 58).

Der Artikel zu den marktweiten Datenmodellen beschreibt noch die Konsultationsfassung von Juli 2026.

Der Aufruf selbst

Der Weg einer MaLo-Ident-Anfrage zeigt das Prinzip:

Die API-Guideline benennt drei Begriffe. Der API-Anbieter stellt einen Webservice bereit, der API-Nutzer ruft ihn als Client auf, der Kommunikationsendpunkt ist die URL samt Port. Anbieter und Nutzer wechseln je Schritt: Bei der MaLo-Ident ruft der Lieferant den Netzbetreiber, danach der Netzbetreiber den Lieferanten (API-Guideline 1.0b, Kap. 2.2).

Statuscodes. Positiv gibt es nur 202. Es bedeutet „technisch angenommen“, Nutzdaten liefert es nicht. Die fachliche Antwort kommt asynchron, sofern die Prozessbeschreibung eine vorsieht (Kap. 3.5). Fehler melden 400, 401, 404, 405, 415, 429, 500, 503 und 504. Bei 429 hat der Client zu viele Anfragen gestellt, bei 503 und 504 soll er später wiederholen, und zwar mit Pausen (Kap. 3.6).

Versionierung. Semantic Versioning, die URL trägt den Major-Anteil (/v1), die Antwort den vollen Stand im Header X-BDEW-VERSION. Änderungen kommen bis zu zweimal im Jahr, der Umstellungszeitraum beträgt mindestens drei Monate (Kap. 3.2).

Die vier Kennungen. Jeder Aufruf trägt transactionId (uuid) und creationDateTime, als HTTP-Kopfzeilen. Dazu zwei Regeln, die die Fassung 1.0b gegenüber 1.0a präzisiert hat (Kap. 3.4.1):

• Bei jedem Aufruf und jedem Retry vergibt der Client eine neue transactionId. Nur bei einem Retry gibt er in initialTransactionId die transactionId des Erstaufrufs mit. Ist die Anfrage kein Retry, darf initialTransactionId nicht enthalten sein.
• Eine asynchrone Antwort trägt in referenceId die initialTransactionId des ursprünglichen Aufrufs, falls es eine gab, sonst dessen transactionId.

Die Nutzdaten sind ein JSON-Objekt im Body, UTF-8 ohne Byte Order Mark, I-JSON nach RFC 7493. JSON-Objekte in Kopfzeilen oder Query-Parametern sind nicht erlaubt (Kap. 3.7).

Sicherheit: TLS, Signatur, Zertifikate

Die Regelungen zum Übertragungsweg für API-Webdienste (Version 1.1, Anlage zu Mitteilung Nr. 46) schreiben die kryptographischen Vorgaben der BSI TR-03116-3 und die Smart-Metering-PKI nach § 52 Abs. 4 MsbG vor. Aus ihnen folgen drei Ebenen (RzÜ API-Webdienste 1.1):

• Netz und Transport (Kap. 3.1, 3.2). Endpunkte sind DNS-Namen, keine IP-Adressen. IPv4 ist Pflicht, IPv6 soll implementiert sein. TLS nach TR-03116-3 mit Server Name Indication.
• Signatur (Kap. 3.3). Jede Interaktion mit Nutzlast wird signiert, Request wie synchrone Response. In die Signatur gehen Ressource samt Query-Parametern, die Kopfzeilen creationDateTime, transactionId und, falls vorhanden, initialTransactionId sowie die Nutzlast ein, das JSON vorher kanonisiert nach RFC 8785. Digest, Signatur und Zertifikat stehen base64-kodiert in X-BDEW-DIGEST, X-BDEW-SIGNATURE und X-BDEW-CERT.
• Keine Inhaltsverschlüsselung. Parameter und Nutzlast werden nicht verschlüsselt; der Schutz kommt von TLS und der Signatur. Alle für die fachliche Verarbeitung nötigen Parameter müssen in der Signatur stehen. Weitere Kopfzeilen sind rein informatorisch und dürfen die Verarbeitung nicht beeinflussen.

Zertifikat EMT.API (Kap. 4). API-Nutzer und -Anbieter sind passive EMT der SM-PKI. Das Zertifikat hat den CommonName <org>.EMT.API<extension>, die MP-ID im Feld Organisational Unit und im Alternativnamen (URI) die Adresse des Verzeichnisdienstes. Ein Zertifikat kann für mehrere API-Webdienste dienen. Nachfolgezertifikate müssen spätestens zehn Werktage vor dem Ungültigwerden bereitstehen; ältere Zertifikate für Steuerhandlungen dürfen bis zum Gültigkeitsende weiterlaufen (Übergangsregel Kap. 4.4).

Verzeichnisdienst (Kap. 4.2). Anders als bei AS4, wo die Adresse im Zertifikat steht und bei der CA abgerufen wird, braucht jeder Marktpartner einen dezentralen Verzeichnisdienst. Er veröffentlicht zur API-Kennung (etwa API00003) den Endpunkt als URL. Ohne Eintrag bleibt der Dienst für den Partner unauffindbar. Den Vergleich zum Dateiweg zieht AS4 und die Smart-Metering-PKI.

Die Zertifikatsregeln ändern sich: Die 1.x-Regelungen für EDIFACT- und Redispatch-Daten bekommen nach Mitteilung Nr. 58 eine Version 1.11 mit Änderungen zu mTLS ab 01.04.2027. Ob die RzÜ API-Webdienste nach Version 1.1 fortgeschrieben wurden, ist hier nicht geprüft.

Beispiel: MaLo-ID ermitteln

Ein Lieferant will beliefern und kennt die MaLo-ID nicht. Er ruft den Netzbetreiber auf. Die OpenAPI-Definition maloIdentV1 (Version v1.0.0, Repository EDI-Energy/api-electricity) führt dafür drei POST-Pfade (OpenAPI-Definition):

• /maloId/request/v1 (Prüfi 20000): Suchkriterien an den Netzbetreiber.
• /maloId/dataForMarketLocationNegative/v1 (Prüfi 20010): Rückmeldung mit Entscheidungsbaum und Antwortcode.
• /maloId/dataForMarketLocationPositive/v1 (Prüfi 20020): gefundene Marktlokation mit Parametern.

Vereinfachtes Beispiel für den Body der Anfrage:

{
  "identificationDateTime": "2026-10-01T00:00:00Z",
  "energyDirection": "consumption",
  "identificationParameterAddress": {
    "zipCode": "10117",
    "city": "Berlin"
  }
}

Der Netzbetreiber antwortet sofort mit 202. Findet er die Marktlokation, ruft er /maloId/dataForMarketLocationPositive/v1 beim Lieferanten auf. Die referenceId verweist auf die Anfrage, resultPositive enthält die dataMarketLocation mit elfstelliger MaLo-ID, gegebenenfalls mit Messlokationen, Tranchen und technischen Ressourcen. Passt kein Treffer, kommt der negative Pfad mit Antwortcode (Entscheidungsbaum E_0594 laut Anwendungsübersicht). Bricht die Verbindung ab, wiederholt der Client mit neuer transactionId und der alten als initialTransactionId; der Netzbetreiber erkennt den Vorgang wieder.

Den Prozess dahinter, mit Frist und Ablehnungsgründen, zeigt der Ablaufatlas unter MaLo-ID-Ermittlung. Die Lokationen erklärt Die Marktlokation.

Fehlerfälle

• Falscher Weg. Ein API-Prozess wird per EDIFACT geschickt oder umgekehrt. Maßgeblich ist die Spalte „Übertragungsweg“ der Anwendungsübersicht.
• 202 als Bestätigung gelesen. Der Vorgang gilt als erledigt, obwohl die asynchrone Antwort fehlt.
• Antwort ohne referenceId. Sie lässt sich keiner Anfrage zuordnen.
• Retry mit initialTransactionId beim Erstaufruf. Seit 1.0b nicht zulässig; die Kennung gehört nur an den Retry.
• Fachliche Angabe in einem Zusatz-Header. Die Signatur deckt sie nicht ab, die Verarbeitung darf sie nicht auswerten.
• Eintrag im Verzeichnisdienst fehlt. Zertifikat und Endpunkt sind in Ordnung, der Partner findet den Dienst nicht.
• Zertifikatswechsel zu spät. Ohne zehn Werktage Überlappung wird die Umstellung zum Zeitproblem.

Typische Missverständnisse

„API-Webdienste ersetzen AS4.“ Sie gelten nur für die Prozesse, die die Anwendungsübersicht als API führt. Derzeit sind das MaLo-Ident und der Steuerbefehl.

„Der Lieferantenwechsel in 24 Stunden läuft über API.“ Nur die vorgeschaltete MaLo-ID-Ermittlung. Die Anmeldung ist eine UTILMD mit Prüfi 55001 über AS4.

„TLS verschlüsselt die Nutzlast.“ TLS sichert die Verbindung. Die Nutzlast selbst bleibt unverschlüsselt und wird signiert.

„Die API-Guideline legt die Prozesse fest.“ Sie regelt Aufbau, Versionierung, Datentypen und Statuscodes. Welcher Prozess über API läuft, steht in den Festlegungen und der Anwendungsübersicht.

„Es kommen bald viele neue API-Webdienste.“ Zum Stand 01.10.2026 nicht: Die Konsultationsdienste sind zurückgezogen, neue Fälle bleiben in EDIFACT.

Quellen und Pflegehinweis

Tragend sind die API-Guideline 1.0b (01.04.2026), die Regelungen zum Übertragungsweg für API-Webdienste 1.1, die Mitteilungen Nr. 56 und 58 sowie die Anwendungsübersicht der Prüfidentifikatoren 4.0. Das Beispiel stützt sich auf die OpenAPI-Definition im Repository. Dessen Konsultations-Branch und die zurückgezogenen Dienste sind kein Maßstab. Prüfen Sie bei jedem Release die Mitteilungen der Bundesnetzagentur, die Fassung der API-Guideline und den Repository-Stand.

• BDEW: API-Guideline, Version 1.0b
• Regelungen zum Übertragungsweg für API-Webdienste, Version 1.1
• Bundesnetzagentur: Mitteilung Nr. 58
• Bundesnetzagentur: Mitteilung Nr. 56
• EDI@Energy: OpenAPI-Definition zur Ermittlung der MaLo-ID

Abrufdatum aller Quellen: 5. Oktober 2026.