Nutzer-Management-API (bved "on-site-roles", ehemals ARGE)
Einführung
Zweck und Anwendungsbereich
Die Nutzer-Management-API (bved "on-site-roles") erlaubt Ihnen, Nutzer- bzw. Bewohnerwechsel an KALO zu übermitteln und damit eine wichtige Voraussetzung für die Erstellung der unterjährigen Verbrauchsinformation (UVI) zu erfüllen. Was ist die unterjährige Verbrauchsinformation (UVI)
Weiterhin können Sie mithilfe der API Ihren Nutzerdatenstand selbstständig, d.h. ohne Eingriff durch KALO, einsehen und pflegen. Im Detail gehören dazu:
aktuellen Nutzerdatenstand abfragen
Nutzerdatenstand bearbeiten (zum Beispiel Ein-/Auszüge hinterlegen)
Nutzerdaten löschen
Neue Nutzerdaten einfügen
Mehr erfahren über die Endpunkte oder Beispielszenarien „S-COR“ (Nutzer bzw. Bewohner)
Über diese API
Die Nutzer-Management-API ist eine HTTP REST-API nach dem Webservice-Standard „on-site-roles“ vom Bundesverband für Energie- und Wasserdatenmanagement (bved), ehemals Arbeitsgemeinschaft Heiz- und Wasserkostenabrechnung (ARGE). Die dazugehörige API-Definition und Dokumente können Sie hier kostenlos herunterladen: Dokumentation der bved für die API „on-site-roles v1.1“
Bitte beachten Sie: KALO unterstützt aktuell nur die Rolle „S-COR” im Rahmen der unterjährigen Verbrauchsinformation (UVI). Alle anderen Rollen werden aktuell nicht verarbeitet und nicht gespeichert.
Bitte beachten Sie: Die Felder Telefonnummer, Steuernummer und E-Mail-Adresse werden derzeit nicht gespeichert.
Über diese API-Dokumentation
Die nachfolgende Dokumentation bietet Informationen zur Implementierung der API. Mit dieser Dokumentation möchten wir Sie bei der optimalen Nutzung der Nutzer-Management-API v1.1 für die UVI unterstützen.
Erfahren Sie mehr über Fehlermeldungen.
Authentifizierung
Wir bieten Ihnen die Authentifizierung über Bearer Token (OpenIDConnect) oder Basic Auth an, um sowohl den IT-Sicherheitsanforderungen zeitgemäßer Anwendungen zu genügen als auch der brancheneinheitlichen Spezifikation der API.
Ihre API-Zugangsdaten erhalten Sie von Ihrem KALO-Kundenbetreuer aus dem Bereich digitale Lösungen.
Bearer Token (OpenIdConnect)
Sie können die Endpunkte mit einen gültigen Bearer JWT-Token aufrufen. Diesen erhalten Sie über den folgenden OpenID-Token-Endpunkt:
POST https://meine.kalo.de/auth/realms/arge-api/protocol/openid-connect/token
Ersetzen Sie bitte den HTTP Authorization header mit Ihren API-Zugangsdaten (Benutzername:Passwort) im Base64 Format.
curl --location --request POST 'https://meine.kalo.de/auth/realms/arge-api/protocol/openid-connect/token' \
--header 'Authorization: Basic ******='\
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'grant_type=client_credentials'
OpenID Discovery Configuration (.well-known-configuration)
https://meine.kalo.de/auth/realms/arge-api/.well-known/openid-configuration
Basic Auth
Als alternative Authentifizierungsmethode wird HTTP Basic Auth entsprechend der Definition im bved-Standard „on-site-roles“ unterstützt. (siehe bved-Dokumentation für die API „on-site-roles v1.1“ )
Ihre API-Zugangsdaten erhalten Sie auf Anfrage per E-Mail von uns. Kontaktieren Sie uns dafür bitte über unser Kontaktformular.
Endpunkte
Basispfad
Pfad für das Produktivsystem:
https://api.kalo.de/arge/on-site-roles/v1/
Pfad für das Testsystem:
Den Zugriffspfad für die Testumgebung erhalten Sie aus Sicherheitsgründen nur persönlich im Rahmen der Testplanung.
Bitte beachten Sie: Die sogenannte „MSC Number Billingunit“, also die Liegenschaftsnummer im Messdienstleistersystem (auf Englisch „measure service company number “), ist Bestandteil jeder API-Anfrage. Die API unterstützt 9-stellige alphanumerische Nummern, wie sie branchenüblich sind. Das schließt Nummern mit führenden Nullen ein.
Verfügbare Endpunkte im Überblick
Wie in der bved-Dokumentation beschrieben, können Sie unterschiedliche Nutzerdatenänderungen über die Schnittstelle selbst ausführen bzw. KALO mitteilen.
Nutzerwechsel bzw. Nutzerdatenänderungen werden wie folgt an KALO übermittelt.
Nutzerdatenstand abfragen
Nutzerdatenstand übermitteln und bearbeiten
Nutzer (Rollen) löschen
Ergebnis der Nutzerdatenstandübermittlung abrufen (Data-Delivery Status)
Beispielszenarien „S-COR“ (Nutzer bzw. Bewohner)
Im Folgenden finden Sie einige Beispielszenarien bzw. Use-Cases samt technischer Beispielanfragen („Request Body“) für die Rolle S-COR, welche den Empfänger der unterjährigen Verbrauchsinformation (UVI) – sprich den Nutzer oder Bewohner (Mieter oder Eigentümer) – repräsentiert.
Bitte beachten Sie: Aktuell unterstützt KALO keine Mehrfachbelegungen. Es kann nur eine Rolle vom Typen „S-COR“ im gleichen Zeitraum aktiv sein. Ist es gewünscht eine neue Rolle anzulegen, muss die zetlich aktive, aktuelle Nutzerrolle vorher via „UPDATE” mit einem Auszugsdatum beendet werden (siehe Use Case Nr. 1).
Eine Überlappung der in den Rollen definierten Zeiträume ist nicht möglich.
Name | Ist Zustand | Beschreibung | Request Body | |
1 | Übermittlung Nutzerwechsel innerhalb einer Nutzeinheit. | Mustermann wohnt ohne Enddatum innerhalb einer Nutzeinheit. | Nutzer Mustermann zieht zum (DD.MM.JJJJ) aus, Folgenutzer Musterfrau (DD.MM.JJJJ) zieht ein. |
JSON
|
2 | Bereits übermittelte Nutzerwechsel bearbeiten | Das Auszugsdatum von Musterfrau soll angepasst werden | Folgenutzer Meike Musterfrau hat ein späteres Auszugsdatum (DD.MM.JJJJ) mitgeteilt. (Aufbauend auf Use Case Nr. 1) |
JSON
|
3 | Bereits übermittelte Nutzerwechsel löschen. | Musterfrau zieht doch nicht mehr in die Nutzeinheit ein und soll wieder gelöscht werden. | Ursprünglich gelieferter Nutzerwechsel von Musterfrau soll wieder entfernt werden. |
JSON
|
Fehlerbehandlung
Hier finden Sie eine Übersicht an Fehlermeldungen, wie sie einerseits in der bved-Dokumentation enthalten sind sowie darüberhinausgehend von uns definierte Fehlermeldungen und ihre Behandlung.
Zur bved-Dokumentation: https://bved.info/datenaustausch/spezifikationen
HTTP-Antwortcodes
Folgende Standard HTTP-Antwortcodes erhalten Sie von uns:
Antwortcode | Status | Fehlerbeschreibung und Behebungsempfehlung |
---|---|---|
200 | OK | Die Anfrage ist erfolgreich. Die Ressource wird als Antwort zurückgeliefert. |
400 | Bad request | Der Server konnte die Anfrage aufgrund einer ungültigen Anfrage nicht ausführen. Weitere Details zur Ursache wird in der Fehlerantwort mitgeteilt. |
Unauthorized | Eine gültige Authentifizierung ist erforderlich, um die angeforderte Antwort zu erhalten. | |
403 | Forbidden | Ihr API Zugang hat nicht die Berechtigung um diese Nutzerdaten abzufragen oder zu ändern. Kontaktieren Sie ggf. den KALO Kunden-Support |
404 | Not Found | Der Server kann die angeforderte Ressource nicht finden. Weitere Details zur Resource finden Sie in der Antwortfehlermeldung. |
Precondition Failed | Die Anfrage bzw. die zu übermittelnde Datenstruktur enthält nicht die notwendigen Nummern (Msc/ Pm Number) oder ein anderer Rollentyp, als der unterstützte S-COR wurde übermittelt, angefragt. | |
To Many Requests | Ihre Anfragen von der gleichen Aufrufer IP-Adresse wurde aus Sicherheitsgründen geblockt (rate limiting). Versuchen Sie die Anfragen sequentiell verteilt zu stellen. | |
500 | Internal Server Error | Der Server kann die Anfrage nicht beantworten aufgrund eines internen Fehlers. |
Not Implemented | Die Anfragemethode wird vom Server nicht unterstützt und kann nicht bearbeitet werden. | |
Temporarily not available | Der Webservice steht kurzfristig nicht zur Verfügung. Versuchen Sie es zu einem späteren Zeitpunkt noch einmal oder kontaktieren Sie den Kunden Support. |
Fehlermeldungen
Stand: Mai 2025
Synchrone Validierung
Asynchrone Validierung (Data-Delivery Status)
Bitte denken Sie daran, die Verarbeitung Ihres Auftrages mittels der erhaltenen Data Delivery ID auf den Status und eventuelle Fehlermeldungen zu überprüfen (vgl. dazu auch bved Spezifikation, Punkt "(2) Asynchrone Validierung").
Support und Kontakt
Sie benötigen Zugang zu einer unserer Schnittstellen oder haben ein Problem bei der Nutzung der APIs? Nutzen Sie gerne unser Kontaktformular, um uns Ihr Anliegen mitzuteilen. Unsere Experten nehmen schnellstmöglich Kontakt mit Ihnen auf.