Zuerst den Datenfluss klären
Vor Endpunkten und Zugangsschlüsseln steht eine fachliche Frage: Welches System ist für welche Information zuständig? Ein CRM kann zum Beispiel die Kundenadresse führen, während die Warenwirtschaft Aufträge und Lieferstatus verwaltet.
Werden dieselben Felder in beiden Systemen geändert, braucht es eine eindeutige Regel. Sonst läuft die Übertragung zwar technisch durch, überschreibt aber den richtigen Wert mit einem älteren Stand.
- Welches System liefert die Daten?
- Welches System darf einen Wert später noch ändern?
- Welche Felder sind Pflicht und welche dürfen leer bleiben?
- Wie werden bestehende Datensätze und Dubletten erkannt?
Prüfen, was die vorhandene API wirklich kann
Dass ein Anbieter eine API anbietet, heißt noch nicht, dass alle benötigten Daten verfügbar sind. Manche Schnittstellen erlauben nur das Lesen, andere begrenzen Anfragen oder liefern wichtige Informationen erst zeitversetzt.
Vor einem Angebot sollten deshalb Dokumentation, Testzugang und Berechtigungen geprüft werden. Fehlt eine passende API, können Webhooks, CSV-Dateien oder ein kontrollierter Import trotzdem sinnvoll sein.
- Sind alle benötigten Objekte und Felder erreichbar?
- Gibt es einen Testzugang oder eine Sandbox?
- Wie streng sind Limits und Zeitfenster für Anfragen?
- Werden Änderungen aktiv gemeldet oder müssen sie regelmäßig abgefragt werden?
Fehlerfälle vor dem Start festlegen
Kein Fremdsystem ist dauerhaft erreichbar. Verbindungen brechen ab, Pflichtfelder ändern sich oder ein Datensatz enthält einen Wert, den das Zielsystem nicht akzeptiert. Die Schnittstelle muss solche Fälle sichtbar behandeln.
Ein Vorgang sollte wiederholt werden können, ohne dass dadurch eine Bestellung doppelt entsteht. Fachliche Fehler gehören in eine verständliche Fehlerliste. Technische Ausfälle können dagegen oft automatisch erneut versucht werden.
- Temporäre Ausfälle werden später erneut versucht.
- Doppelte Übertragungen werden technisch verhindert.
- Fachliche Fehler sind für zuständige Mitarbeiter verständlich sichtbar.
- Offene Vorgänge verschwinden nicht unbemerkt in einem Protokoll.
Beispiel: Bestellungen zwischen Shop und Warenwirtschaft
Bei einem Händler kommen Bestellungen im Webshop an und werden anschließend von Hand in die Warenwirtschaft übertragen. Gleichzeitig werden Bestände nur in festen Abständen zurück in den Shop geschrieben. Eine doppelte Eingabe oder ein verspäteter Abgleich fällt häufig erst auf, wenn Lager oder Kunden nachfragen.
Für den ersten Ausbau kann eine klar begrenzte Verbindung reichen: Neue Bestellungen werden mit eindeutiger Shop-ID an die Warenwirtschaft übergeben. Der Lagerbestand fließt in einer festgelegten Richtung zurück. Schlägt eine Übertragung fehl, bleibt der Vorgang in einer Warteschlange und erscheint mit verständlichem Grund im Monitoring.
Retouren, Preisregeln und mehrere Lager müssen nicht automatisch zum Start dazugehören. Sie kommen erst hinzu, wenn der grundlegende Datenweg unter echten Bedingungen zuverlässig läuft. So bleibt sichtbar, welche Regel einen Fehler verursacht und welches System den Wert berichtigen muss.
- Zuerst: eine eindeutige Richtung für Bestellung und Bestand festlegen.
- Im Alltag testen: Ausfälle und unvollständige Datensätze kontrolliert wiederholen.
- Später entscheiden: Retouren, Preise und weitere Lager getrennt ergänzen.
Zugriffe und Protokolle begrenzen
API-Schlüssel sollten nur die Rechte erhalten, die für den Datenfluss nötig sind. Ein reiner Bestellimport braucht nicht automatisch Zugriff auf sämtliche Kunden- oder Buchhaltungsdaten.
Auch Protokolle brauchen Grenzen. Für die Fehlersuche reichen häufig interne IDs, Zeitpunkt und Statuscode. Vollständige Kunden- oder Dokumentdaten müssen nicht in jedem Log stehen.
An den Betrieb nach der Übergabe denken
Eine Schnittstelle ist nach der ersten erfolgreichen Übertragung nicht fertig. APIs ändern sich, Zugangsdaten laufen ab und fachliche Regeln entwickeln sich weiter. Deshalb muss feststehen, wer Fehlermeldungen erhält und wer über Anpassungen entscheidet.
Für die Übergabe sind eine kurze technische Dokumentation, ein Überblick über die Datenfelder und ein erreichbares Monitoring wichtiger als ein unübersichtliches Protokoll mit tausenden Einträgen.
Welche Unterlagen für eine erste Einschätzung helfen
Für den Start genügen meist die Namen der beteiligten Systeme, zwei oder drei echte Beispieldatensätze und eine Beschreibung des gewünschten Ablaufs. Zugangsdaten gehören noch nicht in eine erste Anfrage.
Mit diesen Angaben lässt sich klären, ob die vorhandenen Schnittstellen ausreichen, welche Fehlerfälle wichtig sind und welcher Teil zuerst umgesetzt werden sollte.