Offene Schnittstellen als Auswahlkriterium: Was Sie prüfen sollten
Kurz gesagt
Offene Schnittstellen erkennen Sie daran, dass das ERP seine API dokumentiert, die Zugriffe authentifiziert, die Limits angibt, Ereignisse meldet und die Daten maschinenlesbar exportiert. Prüfen Sie alle sechs Punkte im Testsystem. In Deutschland und Österreich verankert Art. 20 DSGVO das Recht, bereitgestellte Personendaten in einem strukturierten, gängigen und maschinenlesbaren Format zu erhalten, sofern die Verarbeitung auf Einwilligung oder Vertrag beruht und automatisiert erfolgt; in der Schweiz gewährt Art. 28 DSG ein vergleichbares Recht auf Datenherausgabe oder -übertragung.
Das Wichtigste
- Sechs Prüfpunkte: dokumentierte API, Authentifizierung, Limits, Webhooks, Exportformate, Testsystem.
- Die OpenAPI Specification 3.2.1 (10. September 2026) beschreibt HTTP-APIs maschinenlesbar; ein Dokument in diesem Format macht den Funktionsumfang ohne Herstellergespräch prüfbar.
- OAuth 2.0 ist der Standard RFC 6749 (IETF, Oktober 2012); für System-zu-System-Anbindungen sieht er den Grant-Typ Client Credentials vor.
- Der HTTP-Statuscode 429 (RFC 6585) zeigt überschrittene Abruf-Limits an; das Retry-After-Feld ist optional.
- Art. 20 DSGVO (ab 25. Mai 2018) gewährt das Recht, bereitgestellte Personendaten in strukturiertem, gängigem, maschinenlesbarem Format zu erhalten, sofern die Verarbeitung auf Einwilligung oder Vertrag beruht und automatisiert erfolgt.
- Das schweizerische DSG (SR 235.1, in Kraft seit 1. September 2023) gewährt in Art. 28 ein Recht auf Datenherausgabe oder -übertragung in einem gängigen elektronischen Format, wenn die Daten automatisiert und auf Einwilligung oder im Zusammenhang mit einem Vertrag bearbeitet werden.
Ob ein ERP offene Schnittstellen hat, zeigt sich nicht in der Funktionsliste, sondern im Testsystem. Die folgende Prüfliste trennt, was ein Anbieter zusagt, von dem, was Sie selbst nachweisen können. Sie gilt für Deutschland, Österreich und die Schweiz.
Worum es bei der Auswahl geht
Offene Schnittstellen sind ein Auswahlkriterium, kein Verkaufsargument. Ein Anbieter kann eine API haben, die nur für die eigene Integration taugt, und eine, die Ihre Anbindungen trägt. Der Unterschied liegt in der Dokumentation, der Authentifizierung, den Limits, den Ereignismeldungen und den Exportformaten. Diese fünf Punkte plus das Testsystem bilden die Prüfliste. Sie ist eine redaktionelle Einschätzung, keine Norm; die Reihenfolge folgt dem Aufwand, den ein fehlender Punkt im Betrieb macht.
Was eine offene Schnittstelle ausmacht
Eine offene Schnittstelle ist eine Programmierschnittstelle (API), die dokumentiert, maschinenlesbar, standardbasiert und ohne Mitwirkung des Anbieters nutzbar ist. Diese Definition ist redaktionell; sie ist keine Norm. Die Tabelle listet die sechs Kriterien mit dem jeweiligen Test. Bestanden gilt je Kriterium nur, wenn der Test ohne Hilfe des Anbieter-Supports auskommt.
| Kriterium | Warum es zählt | So prüfen Sie es | Frage an den Anbieter |
|---|---|---|---|
| Dokumentierte API | Ein OpenAPI-Dokument lässt sich mit Werkzeugen auswerten und macht so Pfad- und Funktionsumfang maschinell prüfbar; eine vollständige handgeschriebene Dokumentation ist ebenfalls prüfbar, erfordert aber mehr Aufwand. | Fordern Sie das OpenAPI-Dokument an und lesen Sie die Pfade und Operationen für Ihre Objekte ab. | “Liefern Sie die API-Dokumentation als OpenAPI-Dokument, und welche Version ist aktuell?” |
| Authentifizierung | Ohne nachvollziehbare Vergabe und Widerruf von Zugangsdaten können Sie eine Anbindung nicht trennen oder beenden. | Prüfen Sie, wie Zugangsdaten entstehen, wie lange sie gelten und wie sie widerrufen werden; bei OAuth 2.0 (RFC 6749) passt für System-zu-System-Anbindungen der Grant-Typ Client Credentials (Abschnitt 4.4). | “Welche Authentifizierungsmechanismen unterstützen Sie, und wie werden Zugangsdaten je Anbindung vergeben und widerrufen?” |
| Abruf-Limits | Unbekannte Limits brechen Anbindungen im Stoßbetrieb; ein dokumentiertes Limit mit definierter Fehlerantwort ist planbar. | Fordern Sie die Limits je Zeitfenster schriftlich an und fahren Sie eine Schleife mit Aufrufen, um die Drosselgrenze zu finden (Status 429, RFC 6585, Abschnitt 4; das Retry-After-Feld ist optional). | “Wie viele Aufrufe je Zeitfenster sind erlaubt, und was antwortet die API bei Überschreitung?” |
| Webhooks | Ohne Ereignismeldungen erkennen Sie Änderungen nur durch wiederholtes Abfragen; das verzögert Prozesse und erhöht die Abrufzahl. | Registrieren Sie in der Testumgebung einen Webhook auf einen Protokoll-Endpunkt, lösen Sie das Ereignis aus und prüfen Sie die eingehende Meldung mit Zeitstempel. Die OpenAPI Specification 3.2.1 kennt ein Feld webhooks für solche Aufrufe (Abschnitt 4.1.1). | “Welche Ereignisse meldet das ERP aktiv, und wie werden fehlgeschlagene Zustellungen abgearbeitet?” |
| Exportformate | Ein ERP, das seine Daten nicht maschinenlesbar herausgibt, bindet Sie an den Anbieter; der Export ist die Voraussetzung für jede spätere Migration. | Erzeugen Sie im Testsystem einen Export von Stammdaten und Bewegungsdaten und stimmen Sie ihn mit den Auswertungen des Systems ab. In Deutschland und Österreich verankert Art. 20 DSGVO das Recht, bereitgestellte Personendaten in einem strukturierten, gängigen und maschinenlesbaren Format zu erhalten, sofern die Verarbeitung auf Einwilligung oder Vertrag beruht und automatisiert erfolgt. | “In welchen Formaten exportieren Sie Stammdaten, Bewegungsdaten und Personendaten, und sind die Formate dokumentiert?” |
| Testsystem | Ohne Testumgebung testen Sie im laufenden Betrieb; ein Schreibtest legt echte Datensätze an. | Fordern Sie einen Testzugang mit eigener Datenbasis an und fahren Sie dieselben Aufrufe wie im Produktivsystem. | “Bereitstellen Sie einen Testzugang mit eigener Datenbasis, und was kostet er?” |
Der rechtliche Anker: Datenübertragbarkeit
In Deutschland und Österreich gilt die Datenschutz-Grundverordnung (DSGVO) unmittelbar. Art. 20 Abs. 1 DSGVO gewährt der betroffenen Person das Recht, die sie betreffenden personenbezogenen Daten, die sie einem Verantwortlichen bereitgestellt hat, in einem strukturierten, gängigen und maschinenlesbaren Format zu erhalten und einem anderen Verantwortlichen ohne Behinderung zu übermitteln. Die Voraussetzung ist, dass die Verarbeitung auf einer Einwilligung (Art. 6 Abs. 1 lit. a DSGVO) oder einem Vertrag (Art. 6 Abs. 1 lit. b DSGVO) beruht und mit automatisierten Verfahren erfolgt (Art. 20 Abs. 1 lit. a und b DSGVO). Die DSGVO gilt ab dem 25. Mai 2018 (Art. 99 Abs. 2 DSGVO).
Für die ERP-Auswahl heißt das: Prüfen Sie, ob das System die Personendaten, die eine betroffene Person bereitgestellt hat, in einem strukturierten, gängigen und maschinenlesbaren Format exportieren kann, sofern die Verarbeitung auf Einwilligung oder Vertrag beruht und automatisiert erfolgt. Das ist ein Auswahlkriterium und ein prüfbarer Punkt im Testsystem, kein Verkaufsargument.
In der Schweiz gilt das revidierte Bundesgesetz über den Datenschutz (DSG, SR 235.1), in Kraft seit dem 1. September 2023. Art. 28 DSG gewährt der betroffenen Person das Recht, die Herausgabe der Personendaten, die sie dem Verantwortlichen bekanntgegeben hat, in einem gängigen elektronischen Format zu verlangen, wenn der Verantwortliche die Daten automatisiert bearbeitet und sie mit der Einwilligung der betroffenen Person oder in unmittelbarem Zusammenhang mit dem Abschluss oder der Abwicklung eines Vertrags zwischen dem Verantwortlichen und der betroffenen Person bearbeitet werden (Art. 28 Abs. 1 lit. a und b DSG). Die betroffene Person kann zudem verlangen, dass der Verantwortliche die Personendaten einem anderen Verantwortlichen überträgt, wenn die Voraussetzungen nach Absatz 1 erfüllt sind und dies keinen unverhältnismässigen Aufwand erfordert (Art. 28 Abs. 2 DSG). Die Herausgabe oder Übertragung ist kostenlos (Art. 28 Abs. 3 DSG). Art. 29 DSG regelt die Einschränkungen dieses Rechts.
Warnsignale in Angebot und Vertrag
- Die API-Dokumentation ist nur auf Anfrage erhältlich und nicht in maschinenlesbarem Format.
- Es gibt keine Testumgebung; Tests sollen im Produktivsystem laufen.
- Es existiert ein einziger unbefristeter Schlüssel für alle Anbindungen, ohne Widerruf je Anbindung.
- Die Abruf-Limits stehen in keinem Dokument, und der Anbieter nennt sie auf Nachfrage nicht schriftlich.
- Der Export liefert nur PDF oder einen Report, nicht die Daten in einem maschinenlesbaren Format.
- Webhooks werden zugesagt, aber im Testsystem nicht demonstriert.
Was Sie im Testsystem versuchen
- Fordern Sie das OpenAPI-Dokument an und lesen Sie die Pfade für Ihre Objekte ab.
- Legen Sie einen Testdatensatz über die API an, ändern Sie ihn und löschen Sie ihn wieder.
- Fahren Sie eine Schleife mit Aufrufen in einem Zeitfenster und notieren Sie die Zahl, ab der die API drosselt.
- Registrieren Sie einen Webhook auf einen Protokoll-Endpunkt, lösen Sie das Ereignis aus und prüfen Sie die eingehende Meldung mit Zeitstempel.
- Erzeugen Sie einen Export von Stammdaten und Bewegungsdaten und stimmen Sie ihn mit den Auswertungen des Systems ab.
- Prüfen Sie den Export von Personendaten im strukturierten, maschinenlesbaren Format (Art. 20 DSGVO, Deutschland und Österreich; Voraussetzung: Einwilligung oder Vertrag, automatisierte Verarbeitung).
Für die tiefere Prüfung der API-Funktionen (Objektabdeckung, Lesen und Schreiben, Versionierung) siehe Offene ERP-Schnittstelle prüfen.
So vergleichen Sie in fünf Schritten
- Listen Sie Ihre geplanten Anbindungen mit den Objekten und der Richtung je Prozess (liest, schreibt oder beides).
- Fordern Sie Dokumentation, Zugangsdaten und Testzugang schriftlich an und notieren Sie das Datum der Anfrage.
- Führen Sie die sechs Tests im Testsystem durch und halten Sie je Test das Ergebnis mit Zahl und Datum fest.
- Tragen Sie die schriftlichen Anbieterantworten zu Limit-, Versions- und Export-Fragen zu den Testergebnissen.
- Bewerten Sie je Kriterium bestanden oder nicht bestanden und entscheiden Sie, welche Nicht-Bestehens-Punkte für Ihre Anbindungen tragbar sind.