Technische Anbindungsunterstützung

Diese Schnittstellendokumentation baut auf der API-Dokumentation auf und konkretisiert sie als technische Anbindungsunterstützung für die Integration mit SHAPTH.

SHAPTH ist die gemeinsame Plattform der Länder für den standardisierten Austausch von Daten im Bereich der Trinkwasserhygiene. Sie unterstützt die digitale Zusammenarbeit zwischen Behörden, Betreibern von Wasserversorgungsanlagen, Zugelassenen Untersuchungsstellen und den jeweils angebundenen Fachverfahren.

Ziel der Schnittstellenbeschreibung ist es, ein gemeinsames technisches Verständnis für die Anbindung der Fachverfahren an SHAPTH sowie für die Nutzung der Schnittstelle zu schaffen. Sie beschreibt unter anderem, welche Schnittstellentypen verwendet werden, wie Umgebungen und Endpunkte aufgebaut sind, wie die Authentifikation erfolgt und wie Fehlerfälle einzuordnen sind.

Der XÖV-Datenstandard „XWasser“ bildet die maßgebliche fachliche und technische Grundlage für den strukturierten Datenaustausch über SHAPTH. Der Standard beschreibt die zugrunde liegenden Datenstrukturen, auf deren Basis Fachverfahren Artefakte wie Prüfberichte, Untersuchungspläne und Jahresberichte SHAPTH-kompatibel erzeugen und übermitteln können.

Die Dokumentation ist in drei Ebenen aufgebaut: Zunächst werden die übergreifenden Grundlagen beschrieben, die für jede Integration relevant sind. Der Quickstart bietet einen kompakten Einstieg in den ersten prüfbaren API-Aufruf. Für die fachliche Umsetzung führen die rollenspezifischen Dokumentationen anschließend zu den passenden Use Cases mit Queries, Variablen, Responses, Parametern, Berechtigungen und Fehlerfällen.

QuickstartKompakter Einstieg in die Anbindung an die SHAPTH-API und die ersten technischen Schritte.

Direkt zu

Wichtige Links>Endpunkte>Authentifikation>Fehlermeldungen>

How-To-Dokumentationen nach Zielgruppe

Hier finden Sie die rollenspezifischen Dokumentationen für die jeweiligen Integrationsrollen.

Softwarehersteller Fachanwendung BehördenSoftwarehersteller LIMS (Labore)Softwarehersteller Fachanwendung Wasserversorger (Betreiber)

Allgemein

Gemeinsame Grundlagen für alle Integrationen

Die folgenden Abschnitte gelten übergreifend und behandeln grundsätzliche Themen der Schnittstelle wie REST vs. GraphQL, Endpunkte, Fehlermeldungen oder Authentifikation.

Hinweis zur Verwendung dieser Dokumentation

Diese Dokumentation bietet einen nutzerfreundlichen Einstieg in die SHAPTH-API, bündelt zentrale Informationen und beschreibt relevante Use Cases detailliert nach Nutzergruppen. Einen vollständigen technischen Überblick über alle Queries, Mutations und Subscriptions der GraphQL-Schemata bieten die Schema-Viewer in den GraphiQL Playgrounds. Dort können Queries, Mutationen und Subscriptions gegen den jeweiligen Endpunkt ausgeführt, getestet und debugged werden.

/api/graphql/service

/api/graphql

Bitte beachten Sie, dass zum Testen der SHAPTH-Schnittstelle ausschließlich die PRE-Umgebung verwendet werden darf. In der PRO-Umgebung dürfen keine Tests durchgeführt werden. Die PRO-Umgebung ist ausschließlich für die produktive Nutzung von SHAPTH vorgesehen.

Disclaimer

Diese Dokumentation dient als ergänzende Hilfestellung für die technische Anbindung an die SHAPTH-Schnittstellen. Sie stellt keine rechtsverbindliche Spezifikation dar und erhebt keinen Anspruch auf Vollständigkeit, Aktualität oder Fehlerfreiheit. Maßgeblich sind die jeweils gültigen technischen Schnittstellenvorgaben, XWasser-Spezifikationen, Codelisten sowie die produktiv bereitgestellten API-Schemata und Endpunkte. Für mögliche Schäden oder Fehlkonfigurationen, die aus der Nutzung dieser Dokumentation entstehen, wird keine Haftung übernommen.

Wichtige Links

Die folgenden externen Quellen ergänzen die Schnittstellenbeschreibung. Sie enthalten Release-Informationen, zusätzliche PDF-Dokumentation sowie die XWasser-Standards, Schemata und Codelisten.

SHAPTH Release Notes und weitere AnbindungshinweiseOpenCode Repository

XWasserstandardmit Codelisten, Schemata und Spezifikation im XRepository

XWasser Schemata und Spezifikationin OpenCode Repository

REST vs. GraphQL

REST für XWasser-Dokumente

REST wird verwendet, wenn XML-Dokumente nach dem XÖV-Datenstandard „XWasser“ übertragen werden, insbesondere Prüfberichte, Untersuchungspläne und Jahresberichte. Die Payload ist XML, der Endpunkt ist versioniert und orientiert sich an der aktuellen XWasser-Version.

GraphQL für Register und Abfragen

GraphQL wird für Abfragen, Änderung und Erstellen von Registerdaten verwendet.
Hierzu ist POST /api/graphql/service der zentrale Endpunkt. Ein Beispiel wäre das Abfragen von Registerdaten von Wasserversorgungsgebieten.

	REST	GraphQL
Wird verwendet für	Upload und Download von XML-Dokumenten	Registereinträge, Listen, Details, fachliche Abfragen, Lese- und Schreibrechte
Payload	`application/xml`	`application/json`
Methode	`POST`, `GET` je Use Case	immer `POST`
Versionierung	im Pfad, `/api/v1/xwasser/v100`	über das bereitgestellte Schema. Kein XWasser-Pfadversionsschema
Authentifikation	(gleicher) Bearer Token für REST und GraphQL

Einordnung: Nachrichten, Registerdaten und Codelisten

REST, GraphQL und XWasser-Codelisten erfüllen unterschiedliche Aufgaben und ersetzen sich nicht gegenseitig. REST ist für den Transport von XWasser-Nachrichten und XML-Dokumenten vorgesehen. Dazu gehören zum Beispiel Prüfberichte, Untersuchungspläne, Jahresberichte sowie administrative Nachrichten wie Quittungen, Rückweisungen oder Nachrichtenabrufe.

GraphQL wird für dynamische SHAPTH-Daten verwendet wie Registerdaten, Listen, Detailabfragen, Suche, Filterung, Sortierung und fachliche Kontextdaten, die für die korrekte Erstellung oder Zuordnung von Nachrichten benötigt werden können. Codelisten sind dagegen kontrollierte und versionierte Wertemengen für einzelne Felder. Im XRepository (siehe oben) hinterlegte Codelisten beantworten die Frage, welcher Wert in einem Feld zulässig ist. Die Rückgaben der GraphQL-Anfragen können zudem den Kontext für Vorgänge über REST geben, zum Beispiel IDs für die Erstellung oder den Versand von Prüfberichten.

Für REST/XWasser-Aufrufe bleibt die Validierung des XML-Dokuments gegen die passende XWasser-Version, die zugehörigen XSDs (XML Schema Definitionen) und die fachlich einschlägigen Codelisten entscheidend. GraphQL kann die dafür benötigten Kontextdaten liefern, ersetzt aber nicht die XWasser-Schema-, Nachrichten- und Codelistenprüfung.

Detaillierung der Versionierung & Rückwärtskompatibilität

Beim REST-Endpunkt für XWasser-Dokumente wird die verwendete XWasser-Version im Pfad abgebildet. Die Versionsnummer wird dabei ohne Punkte an den Pfad angehängt.

REST-Pfadregel

XWasser x.y.z/api/v1/xwasser/vxyz

Beispiel

1.0.0/api/v1/xwasser/v100

Beispiel

1.2.3/api/v1/xwasser/v123

nur Beispiel, aktuelle Version prüfen

Aktuellen XWasserstandard im XRepository öffnen

Bei GraphQL findet diese Form der Endpunkt-Versionierung nicht statt. GraphQL verwendet den jeweiligen GraphQL-Endpunkt und das bereitgestellte Schema.

Rückwärtskompatibilität

Die Aktualisierungen von XWasser richten sich nach dem XÖV-Releasestandard. Dieser sieht halbjährliche Versionswechsel vor. Jede neue Version wird hierbei 6 Monate vor Beginn ihrer Gültigkeit bereitgestellt. Rückwirkend sind mindestens zwei Versionen von XWasser gültig, also die aktuelle und die vorherige Version. Perspektivisch ist vorgesehen, dass ein produktiver Versionswechsel nur einmal jährlich erfolgt.

Endpunkte

Die Umgebung bestimmt den Host: PRE wird für Integration und Tests genutzt, PRO für produktive Aufrufe. Die Detailseiten der UseCases nennen in dieser Dokumentation nur den Endpfad, zum Beispiel /api/graphql/service. Die vollständige URL entsteht durch die Auswahl der passenden Umgebung, zum Beispiel pre.api.shapth.de/api/graphql/service für den Service-Endpunkt auf der PRE.

Bei REST/XWasser-Aufrufen muss außerdem die verwendete XWasser-Version zum versionierten Pfad passen, zum Beispiel v100 für XWasser v1.0.0. Bitte beachten Sie, dass die Endpunkte an die jeweils aktuelle XWasser-Version angepasst werden müssen (siehe Detaillierung der Versionierung & Rückwärtskompatibilität).

Umgebung	API-Host	GraphQL	REST
PRE	`https://pre.api.shapth.de` Integration, Tests und fachliche Abnahme	`/api/graphql/service/api/graphql`	`/api/v1/xwasser/v100`
PRO	`https://api.shapth.de` Produktive API-Aufrufe	`/api/graphql/service/api/graphql`	`/api/v1/xwasser/v100`

Unter nachfolgendem Link können die aktuell bereitgestellten Endpunkte der jeweiligen Umgebung eingesehen werden.PRE-API URLs PRO-API URLs

Weboberfläche als Ergänzung zur API

Die SHAPTH Weboberfläche ist kein API-Endpunkt, kann bei der Arbeit mit der API aber hilfreich sein, zum Beispiel zur fachlichen Prüfung von Registerdaten, Berechtigungen und Testfällen.

PRE Weboberfläche öffnen PRO Weboberfläche öffnen

GraphQL Service und Legacy-Endpunkte

Endpunkt	Status	Veränderung bei bestehenden GraphQL-Endpunkten
`/api/graphql/service`	Zielendpunkt	Konsolidierte API für neue Integrationen, inklusive Register, Listen, Details, Suche, Sortierung und Filterung
`/api/graphql`	teilweise legacy / Web-GraphQL	Enthält weiterhin Funktionen, die noch nicht vollständig migriert sind, zum Beispiel Prüfbericht-Metadaten und Download-URL-Ermittlung über `qualityReports` und `qualityReportById`
`/api/graphql/registry`	deprecated	Frühere Register-API, wird durch `/api/graphql/service` ersetzt

Veränderung bestehender GraphQL-Endpunkte

Der neue GraphQL-Endpunkt https://pre.api.shapth.de/api/graphql/service wurde integriert. Die bestehende API unter https://pre.www.shapth.de/api/graphql ist weiterhin erreichbar und produktiv nutzbar, wird jedoch nicht mehr weiterentwickelt. Es finden daher keine Updates und Erweiterungen für /api/graphql mehr statt.

Die bestehende API unter https://pre.www.shapth.de/api/graphql/registry wird zukünftig ebenfalls durch https://pre.api.shapth.de/api/graphql/service ersetzt und wird ebenfalls nicht mehr weiterentwickelt.

Was auf der neuen /api/graphql/service verfügbar ist

/api/graphql/service stellt die konsolidierte GraphQL-API-Oberfläche für SHAPTH 1 und SHAPTH 2 bereit. Dazu gehören Verbesserungen in den Bereichen Suche, Sortierung und Filterung.

Zusätzlich enthält /api/graphql/service Funktionalitäten, die ausschließlich hier verfügbar sind.

Zur klareren Trennung der Zuständigkeiten wurden die Listen-Queries für Behörden angepasst:

officialList liefert alle Behörden, inklusive oberer Landesbehörden, mittlerer Landesbehörden und Gesundheitsämter. Damit entspricht officialList dem, was zuvor authorityList geliefert hat.
authorityList liefert nur noch Gesundheitsämter, konkret Gesundheitsämter (GA), Wasseramt (WA) und Sonstige (SO).
federalStateList liefert nur obere Landesbehörden.
federalStateBranchList liefert nur mittlere Landesbehörden.

Was in /api/graphql verfügbar ist, aber noch nicht in /api/graphql/service

Folgende Bereiche sind aktuell nur in /api/graphql verfügbar und noch nicht in /api/graphql/service enthalten:

Benutzer- und Client-Verwaltung, einschließlich Erstellung von API-Clients und zugehöriger Benutzerfunktionen.
Role Updates sowie Funktionen rund um Rollen- und Rechteverwaltung.
Berichtswesen, dessen Migration nach /api/graphql/service noch in Arbeit ist. Dazu gehören Prüfberichte, Untersuchungspläne und Jahresberichte.

Diese Module sind bis zur vollständigen Migration weiterhin produktiv über /api/graphql verfügbar.

Was ausschließlich in /api/graphql/service verfügbar ist

Das neue Register Wasserversorgungsgebiete und alle zugehörigen Funktionalitäten werden ausschließlich über /api/graphql/service bereitgestellt. Sie stehen nicht über /api/graphql oder /api/graphql/registry zur Verfügung.

Authentifikation

Die Authentifikation ist für REST und GraphQL identisch. Alle API-Aufrufe verwenden OAuth2 Client Credentials. Der erhaltene access_token wird anschließend in jedem Request als Bearer Token im Header Authorization übergeben.

Die Beispiele auf dieser Seite verwenden die PRE-Umgebung. Die PRO-Umgebung wird noch ergänzt.

AutorisierungsframeworkOAuth 2.0

Grant Typeclient_credentials

Benötigtclient_id + client_secret

RückgabeBearer Token

Technischer Client und fachliche Rollen

Der technische Client und die fachlichen Rollen unterscheiden sich, müssen jedoch zueinander passen.

Das bedeutet, dass die Client-Credentials zur jeweiligen Autor- beziehungsweise Leserrolle (SHAPTH-IDs) passen müssen. Beim Senden einer Nachricht muss der Client berechtigt sein, für den im XML-Dokument angegebenen fachlichen Autor zu handeln. Beim Abrufen von Nachrichten muss der Client entsprechend berechtigt sein, Nachrichten für den fachlichen Leser abzurufen.

Ein konkretes Beispiel ist der Versand eines Prüfberichts: Hier müssen die hinterlegten Client-Credentials mit der im XML-Dokument an der Stelle des Autors angegebenen SHAPTH-ID übereinstimmen.

Auszuführende Schritte

Zugangsdaten vorbereiten

Für die Authentifizierung werden Zugangsdaten für den technischen API-Client benötigt.

client_idclient_secret

Client-ID und Secret in PRE abrufen

In der PRE-Umgebung werden die Zugangsdaten über die SHAPTH-Weboberfläche bereitgestellt. Melden Sie sich mit den zugesendeten Testzugängen unter https://pre.www.shapth.de an und navigieren Sie anschließend zum passenden Rollenbereich.

Passende Rolle auswählen.
Je nach Rolle zu Zuständige Behörden, Zugelassene Untersuchungsstellen oder Betreiber wechseln.
Beim eigenen Eintrag unter Aktion die Detailansicht öffnen.
In der Detailansicht nach unten scrollen und die Angaben zur Anbindung von Drittsoftware übernehmen.

Client-ID und Secret in PRO

Die produktiven Client-Credentials sind mit dem jeweiligen Kunden abzustimmen. Die Nutzung der PRO-Umgebung ist erst als letzter Schritt der Anbindung vorgesehen. Tests und fachliche Abnahmen dürfen ausschließlich in der PRE-Umgebung erfolgen.

Der Wechsel von PRE zu PRO erfordert die Anpassung der verwendeten Endpunkte beziehungsweise Hosts (siehe Kapitel Endpunkte). Funktional ändert sich der Ablauf dabei nicht, d.h. dieselben Use Cases, Requests und fachlichen Schritte werden dann final gegen die produktive Umgebung ausgeführt.

Token-Endpunkt PRE

https://pre.id.shapth.de/realms/shapth/protocol/openid-connect/token

Token-Endpunkt PRO

https://id.shapth.de/realms/shapth/protocol/openid-connect/token

Access Token anfordern

Sprache

curl -X POST "https://pre.id.shapth.de/realms/shapth/protocol/openid-connect/token" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "client_id=<CLIENT_ID>" \
  -d "client_secret=<CLIENT_SECRET>" \
  -d "grant_type=client_credentials"

API mit Bearer Token aufrufen

Der Token wird unabhängig vom technischen Schnittstellentyp an REST- und GraphQL-Endpunkte übergeben. Das folgende Beispiel verwendet PRE. In PRO wird derselbe Pfad auf dem produktiven API-Host aufgerufen.

Authentifizierter GraphQL Request

Sprache

curl -X POST "https://pre.api.shapth.de/api/graphql/service" \
  -H "Authorization: Bearer <ACCESS_TOKEN>" \
  -H "Content-Type: application/json" \
  --data '{
    "query": "<GRAPHQL_QUERY>",
    "variables": {
      "input": {}
    }
  }'

GraphQL Playground für manuelle Tests nutzen

GraphQL Playground als Testoberfläche

Der GraphQL Playground kann für manuelle GraphQL-Tests genutzt werden. Er ist ausschließlich für GraphQL-Anfragen vorgesehen. REST- und XWasser-Aufrufe wie Uploads oder Downloads werden über HTTP-Clients, cURL, PowerShell oder fachliches Testtooling ausgeführt. Öffnen Sie die PRE-Umgebung und setzen Sie im Bereich Headers den Authorization-Header mit dem zuvor angeforderten Bearer Token.

PRE Playground öffnen

Header im Playground

{
"authorization": "Bearer <TOKEN>"
}

HTTP-Statuscodes

Erfolgsebenen nach dem API-Aufruf

Ein erfolgreicher HTTP-Aufruf bedeutet nicht automatisch, dass ein fachlicher Vorgang endgültig angenommen wurde. Angebundene Systeme sollten deshalb mehrere Ebenen getrennt betrachten: Der HTTP-Erfolg zeigt, dass der Request technisch entgegengenommen oder verarbeitet wurde. Eine technische XWasser-Quittung, zum Beispiel administration.quittung.0020, bestätigt die Nachricht auf Nachrichtenebene. Die fachliche Annahme oder Bewertung beschreibt dagegen, ob der fachliche Inhalt geprüft und in einen fachlichen Bearbeitungsstand überführt wurde. Je nach Prozess kann dies über eigene fachliche Status- oder Folgemeldungen erfolgen.

Eine administration.rueckweisung.0010 kann anzeigen, dass eine Ursprungsnachricht zurückgewiesen wurde. HTTP-Statuscodes, technische Quittungen, Rückweisungen und fachliche Folgemeldungen sollten daher getrennt ausgewertet und protokolliert werden.

Diese Tabelle bildet häufig verwendete HTTP-Fehlercodes ab. Sie ist keine vollständige HTTP-Spezifikation. Weitere Hinweise zu Statuscodes werden zentral auch auf der Wiki-Seite SHAPTH-Wiki HTTP-Fehlercodes gepflegt.

Status	Fehlermeldung	Kategorie	Beschreibung
`400`	`invalid context value for ty Hdp, cannot create api client for inactive federal state branch`	Fehlerhafte Anfrage	Fehlerhafte Anfrage oder falscher fachlicher Kontext.
`401`	`(aus Sicherheitsgründen werden hier keine Details angezeigt)`	Authentifizierungsfehler	Fehler bei Anmeldung, API-Aufruf oder Authentifizierung.
`403`	`(aus Sicherheitsgründen werden hier keine Details angezeigt)`	Fehlende Berechtigung	Die Anmeldung war erfolgreich, für die angefragte Aktion fehlt jedoch die Berechtigung.
`404`	`404 - Not found / Seite nicht gefunden`	Nicht gefunden	Seite oder Ressource wurde nicht gefunden.
`409`		Konflikt	Konflikt im fachlichen oder technischen Ablauf, z. B. falsches Dateiformat oder nicht versendbarer Prüfbericht.
`500`		Serverfehler	Server nicht erreichbar oder interner Serverfehler.

Fehlermeldungen

API-Fehlermeldungen

Die folgende Übersicht zeigt die zentral hinterlegten API-Fehlermeldungen. Die Meldungen werden auch auf der Wiki-Seite SHAPTH-Wiki API-Fehlermeldungen gepflegt und aktualisiert. HTTP-Statuscodes sind im Kapitel HTTP-Statuscodes beschrieben.

Fehlermeldung	Beschreibung	Mögliches Auftreten
`the actor entity is deactivated`	Der Registereintrag des Akteurs ist deaktiviert. Daher kann der Akteur auf SHAPTH keine Handlungen vornehmen.	Erstellen, Bearbeiten, Löschen eines Registereintrags
`user is not active`	Der Benutzer oder Registereintrag des Akteurs ist deaktiviert. Daher kann der Akteur auf SHAPTH keine Handlungen vornehmen.	API-Aufruf mit inaktivem Benutzer oder Akteur
`invalid ident '{0}'`	Der Akteur ist nicht berechtigt oder eine Kennung ist fachlich ungültig.	API-Aufruf mit ungültiger oder nicht berechtigter Kennung
`only {0} actor can create entity`	Der Akteur ist nicht berechtigt, einen Registereintrag zu erstellen.	Erstellen eines Registereintrags
`{0} actor cannot create entity for other {0}`	Der Akteur ist nicht berechtigt, für andere Registereinträge zu erstellen.	Erstellen eines Registereintrags
`actor cannot create entity for other federal state`	Der Akteur ist nicht berechtigt, für andere Bundesländer Registereinträge zu erstellen.	Erstellen eines Registereintrags
`actor cannot create entity for other federal state branch`	Der Akteur ist nicht berechtigt, für andere Regierungsbezirke Registereinträge zu erstellen.	Erstellen eines Registereintrags
`only applicants with idp attributes can create a {0}`	Für die Erstellung werden passende IDP-Attribute des Antragstellers benötigt.	Erstellen eines Registereintrags durch Antragsteller

Formate relevanter IDs

In dieser Dokumentation werden in Beispielen regelmäßig Dummy-IDs verwendet. Zur Orientierung dient die nachfolgende Tabelle, welche die Formate der jeweiligen IDs erläutert. Die Dummy-IDs müssen im Anwendungsfall durch eine passende SHAPTH-ID ersetzt werden. Diese können Sie aus GraphQL-Abfragen oder aus der SHAPTH-Weboberfläche entnehmen.

Die ersten drei Beispiele beziehen sich exemplarisch auf in Bayern liegende Akteure.

ID-Bezug	Beispielformat
Obere Landesbehörde	`BY000LB000`
Behörde	`BY000GA000`
Zugelassene Untersuchungsstelle	`D-PL-00000-00-00-00BY0`
Betreiber	`BT0000000000000000`

GraphQL-Variablen und Listenabfragen

Viele GraphQL-Listenabfragen in SHAPTH folgen demselben Muster: Die Query nimmt ein input-Objekt entgegen. Darin können je nach Schema Suche, Filter, Pagination und Sortierung kombiniert werden. Welche Optionen fachlich unterstützt werden, hängt vom jeweiligen Query-Typ ab. Die Detailseiten zeigen deshalb nur die Variablen, die im konkreten Use Case verwendet werden.

FeldDetails

input

SchemaNullable

Typ...ListInput

Container für optionale Steuerungsparameter einer Listenabfrage. Nicht jede Query unterstützt alle Unterobjekte.

SchemaNullable

Typ...Search

Textbasierte Suche innerhalb der vom Schema freigegebenen Felder.

filter

SchemaNullable

Typ...Filter

Fachliche Eingrenzung der Ergebnisliste über vom Schema definierte Filterfelder.

pagination

SchemaNullable

TypPagination

Seitenweise Ausgabe der Ergebnisliste.

pagination

page

SchemaNullable

TypInt

Index der angeforderten Ergebnisseite.

limit

SchemaNullable

TypInt

Maximale Anzahl der zurückgegebenen Einträge pro Seite.

sort

SchemaNullable

Typ...Sort

Sortieroptionen für die Ergebnisliste.

sort

order

SchemaNullable

TypSortOrder

Sortierreihenfolge, sofern die Query Sortierung unterstützt. Typische Werte sind `ASC` und `DESC`.

Beispiel-Variablen für eine Listenabfrage

{
"input": {
  "search": {
    "...SearchField": "Suchbegriff"
  },
  "filter": {
    "...FilterField": "FILTER_WERT"
  },
  "pagination": {
    "page": 0,
    "limit": 100
  },
  "sort": {
    "by": "...SortField",
    "order": "ASC"
  }
}
}

Versionierung

Version

1.0

Stand

Juli 2026

Status

Produktiv

Doku-Basis

XWasser-Version 1.0.0

Technische Anbindungsunterstützung

Gemeinsame Grundlagen für alle Integrationen

REST für XWasser-Dokumente

GraphQL für Register und Abfragen

Rückwärtskompatibilität

Token-Endpunkt PRE

Token-Endpunkt PRO

Erfolgsebenen nach dem API-Aufruf

API-Fehlermeldungen

On this page