Offene ERP-Schnittstelle prüfen: Welche API-Funktionen zählen?
Kurz gesagt
Die API Ihres ERP taugt für Ihre Anbindungen, wenn sie sieben Kriterien besteht: die Objekte Ihrer Prozesse, Lesen und Schreiben je Objekt, dokumentierte Abruf-Limits, eine fest verankerbare Version, eine nachvollziehbare Authentifizierung, Ereignis-Meldungen und eine Testumgebung. Je Kriterium planen Sie einen halben bis ganzen Tag ein, sofern Dokumentation, Zugangsdaten und Testumgebung vorliegen. Das Vorgehen gilt für Deutschland, Österreich und die Schweiz.
Das Wichtigste
- Sieben Kriterien: Objektabdeckung, Lesen und Schreiben, Abruf-Limits, Versionierung, Authentifizierung, Webhooks, Testumgebung; je Kriterium ein Bestehens-Test mit eingeplanter Testzeit.
- Die OpenAPI Specification, aktuelle Fassung 3.2.1 vom 10. September 2026, beschreibt HTTP-Schnittstellen maschinenlesbar; ein Dokument in diesem Format macht Pfad- und 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, und Server müssen 429 nicht verwenden.
- OpenAPI Specification und RFCs binden nicht durch Gesetz, sondern allenfalls durch Vertrag; die Kriterien sind deshalb Prüffragen, keine gesetzlichen Anforderungen.
Eine Programmierschnittstelle (API) am ERP ist offener als ein Dateiexport, aber offen ist nicht gleich tauglich. Ob Ihre geplanten Anbindungen daran arbeiten können, entscheidet sich nicht am Umfang der Funktionsliste des Herstellers, sondern daran, ob die Objekte, Richtungen und Rahmenbedingungen Ihrer Prozesse abgedeckt sind. Diesen Artikel lesen Sie als Anleitung für eine Prüfung mit Messlatte: Sieben Kriterien, je ein Test, je ein Bestanden oder Nicht bestanden. Für die Einordnung der Schnittstellen-Offenheit vor einer Kaufentscheidung siehe Offene Schnittstellen als Auswahlkriterium.
Worum es bei der Prüfung geht
Geprüft wird die API des ERP, das Sie betreiben oder beschaffen wollen, gegen Ihre Anbindungsliste: Shop, Lagergeräte, Auswertungen, Dienstleister oder eigene Skripte. Planen Sie je Kriterium einen halben bis ganzen Tag Testzeit ein; Voraussetzung sind Zugang zur Dokumentation, Zugangsdaten und, wenn vorhanden, eine Testumgebung. Was Sie nicht selbst testen können, fragen Sie beim Hersteller schriftlich; eine mündliche Zusage zählt nicht als Ergebnis.
Zwei technische Standards dienen als Maßstab, ohne selbst zu binden: Die OpenAPI Specification beschreibt HTTP-Schnittstellen maschinenlesbar und herstellerneutral (aktuelle Fassung 3.2.1, veröffentlicht am 10. September 2026 von der OpenAPI Initiative). OAuth 2.0 nach RFC 6749 regelt die Vergabe von Zugriffsberechtigungen. Beide binden nicht durch Gesetz, sondern höchstens dann, wenn ein Vertrag sie festschreibt.
Die Kriterien und ihre Tests
Die Tabelle listet die sieben Kriterien mit dem jeweiligen Test. Bestanden gilt je Kriterium nur, wenn der Test ohne Hilfe des Hersteller-Supports auskommt.
| Kriterium | Was es entscheidet | Bestehens-Test: bestanden, wenn … |
|---|---|---|
| Objektabdeckung | ob die Datensätze Ihrer Prozesse (etwa Artikel, Kunden, Aufträge, Lieferungen, Bestände) über die API erreichbar sind | Sie für jedes Objekt Ihrer Anbindungsliste einen Abruf mit Feldliste durchführen und jedes Objekt die Felder liefert, die Ihr Prozess braucht; ein fehlendes Objekt oder Pflichtfeld ist Nicht bestanden |
| Lesen und Schreiben | welche Richtungen je Objekt möglich sind, nicht nur das Lesen von Daten | Sie je Objekt einen Testdatensatz anlegen, ändern und löschen und jede Operation mit dokumentiertem Ergebnis zurückmeldet; ein Objekt, das Ihr Prozess beschreiben muss, nur gelesen werden kann, ist Nicht bestanden |
| Abruf-Limits | wie viele Aufrufe je Zeitfenster erlaubt sind und was bei Überschreitung passiert | Sie eine Schleife mit Aufrufen in einem Zeitfenster fahren (Beispielannahme: 500 Abrufe je Stunde), die Aufrufzahl notieren, ab der die API drosselt oder ablehnt (etwa mit dem Status 429, RFC 6585, Abschnitt 4), und diese Zahl mit Ihrem geplanten Volumen im selben Zeitfenster vergleichen; ein undokumentiertes Limit ohne definierte Fehlerantwort ist Nicht bestanden |
| Versionierung | ob Sie Ihre Anbindung auf eine feststehende Version setzen können und Änderungen ankündigt werden | Sie eine Version identifizieren und festzurren können, etwa über eine Version im Aufrufpfad, und Ihnen die Frist schriftlich genannt wird, wie lange alte Versionen laufen; beides fehlt, ist Nicht bestanden |
| Authentifizierung | wie Zugangsdaten entstehen, wie lange sie gelten und wie sie widerrufen werden | Sie ein Zugangsdatenpaar nach Dokumentation beschaffen, es im Authorization-Feld nutzen (bei OAuth-2.0-Bearer-Tokens nach RFC 6750, Abschnitt 2.1), den dokumentierten Ablauf abwarten und die Erneuerung wiederholen; nicht getrennt widerrufbare, unbegrenzt gültige Festwerte für alle Anbindungen gemeinsam sind Nicht bestanden |
| Webhooks | ob das ERP Ereignisse aktiv meldet oder ob jede Änderung durch Abfragen erkannt wird | Sie in der Testumgebung einen Webhook auf einen Protokoll-Endpunkt registrieren, das Ereignis (etwa neuer Auftrag) auslösen und die eingehende Meldung mit Zeitstempel vorfinden; eine Auslegung nur über wiederholtes Abfragen ohne Ereignismeldung ist Nicht bestanden |
| Testumgebung | ob Sie Anbindungen entwickeln und prüfen können, ohne Produktivdaten zu gefährden | Sie am selben Tag einen eigenen Testzugang mit eigener Datenbasis erhalten und dieselben Aufrufe wie im Produktivsystem fahren können; Testen ausschließlich im Betrieb oder eine Testumgebung ohne Ihre Module ist Nicht bestanden |
Zur Einordnung des Kriteriums Webhooks: Die OpenAPI Specification 3.2.1 kennt ein Feld webhooks für Ereignismeldungen, die der API-Anbieter unabhängig von einem Aufruf sendet, und ein Feld callbacks für Meldungen, die an eine vorangegangene Operation gebunden sind (Abschnitte 4.1 und 4.18). Beide beschreiben Aufrufe, die der API-Anbieter an den Konsumenten sendet.
Zur Einordnung der Kriterien Abruf-Limits und Versionierung: Ein Pflichtfeld für Zeitfenster-Limits enthält die geöffnete Fassung 3.2.1 nicht, und RFC 6585 macht den Status 429 sowie das Retry-After-Feld für Server optional. Das Pflichtfeld info.version des OpenAPI-Dokuments (Abschnitt 4.2) benennt die Version des Dokuments, nicht die adressierbare API-Version. Wo Ihre Grenzwerte stehen, entscheidet deshalb die Herstellerdokumentation; das ist Teil des Tests.
Welche Kosten und Vertragspunkte dazukommen
Die Prüfung der Funktionen sagt nicht, was die Nutzung kostet. Klären Sie diese Felder je Angebot schriftlich; ein leeres Feld ist eine offene Frage, keine Null.
| Kostenfeld | Was Sie eintragen |
|---|---|
| Freischaltung | einmaliger Betrag für die API-Nutzung, falls vorhanden |
| Laufende Nutzung | Betrag je Monat oder Jahr, enthaltene Abruf-Kontingente |
| Mehrabrufe | Preis für Kontingent-Erhöhung, falls Limits greifen |
| Testumgebung | Betrag für den Testzugang, falls berechnet |
| Unterstützung | Preis für Hersteller-Support bei Anbindungsfragen, Reaktionszeit |
| Vertragsseite | Laufzeit und Kündigung des API-Vertrags, getrennt vom ERP-Vertrag |
Warnsignale in Dokumentation und Angebot
- Abruf-Limits stehen in keinem Dokument, und der Hersteller nennt sie auf Nachfrage nicht schriftlich.
- Es gibt keine Testumgebung; Tests sollen im Produktivsystem laufen.
- Es existiert ein einziger unbefristeter Schlüssel für alle Anbindungen, ohne Widerruf je Anbindung.
- Versionsänderungen werden ohne Ankündigungsfrist ausgerollt.
- Die Dokumentation ist nur auf Anfrage erhältlich und nicht in auswertbarem Format.
- Schreibzugriffe auf Auftrags- oder Bestandsdaten sind nur über eine Dienstleistung des Herstellers möglich.
Welche Kriterien für welche Anbindung wiegen
Die Tabelle ordnet die Kriterien je Anbindung nach unserem redaktionellen Urteil; Ihre Prozesse können ein anderes Gewicht setzen.
| Anbindung | Kriterium mit dem größten Gewicht | Grund |
|---|---|---|
| Shop oder Marktplatz | Webhooks, Lesen und Schreiben | Bestellungen sollen ohne Abfrage-Verzögerung entstehen und Status zurückschreiben |
| Lagergeräte und Kommissionierung | Objektabdeckung, Abruf-Limits | Bestände und Bewegungen fallen in großen Mengen an und müssen vollständig erreichbar sein |
| Auswertungen und Berichte | Objektabdeckung, Versionierung | Felder müssen über alle Auswertungsobjekte hinweg stabil bleiben |
| Eigene Skripte und Automatisierung | Testumgebung, Abruf-Limits | jede Erweiterung bringt neue Tests und wiederkehrende Abrufe mit |
Zur Frage, ob Sie die Anbindung selbst entwickeln oder über eine Plattform laufen lassen, siehe Integrationsplattform oder Einzelschnittstellen.
So prüfen Sie in sechs Schritten
- Listen Sie Ihre geplanten Anbindungen mit den Objekten und der Richtung je Prozess (liest, schreibt oder beides).
- Fordern Sie Dokumentation, Zugangsdaten und Testzugang an; notieren Sie das Datum der Anfrage.
- Führen Sie die sieben Tests der Tabelle durch und halten Sie je Test das Ergebnis mit Zahl und Datum fest, etwa die Abruf-Nummer, ab der die API drosselt.
- Übertragen Sie die Kostenfelder je Angebot und markieren Sie offene Felder als Frage.
- Legen Sie die schriftlichen Herstellerantworten zu Limit-, Versions- und Support-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 (unsere Empfehlung: Testumgebung und Authentifizierung sind keine Verhandlungsfelder).
Für die Zeit nach der Freigabe einer Anbindung gilt: Fehler im Betrieb erkennen und wiederholbar abarbeiten ist ein eigener Vorgang, beschrieben in Schnittstellenfehler überwachen.