Wenn Aufträge aus dem Shop per Excel ins ERP wandern, Lagerbestände erst am nächsten Morgen stimmen und der Kundenservice zwischen drei Systemen sucht, fehlt selten ein weiteres Tool. Meist fehlt die Verbindung. Dieser API Integration Leitfaden zeigt, wie mittelständische Unternehmen Schnittstellen so planen, dass Daten verlässlich fließen, Zuständigkeiten klar bleiben und der Go-Live keine Schweißperlen verursacht.
Eine API ist keine Magie und auch kein Selbstzweck. Sie ist eine definierte technische Vereinbarung: Ein System stellt Daten oder Funktionen bereit, ein anderes darf sie nach festen Regeln nutzen. Richtig umgesetzt verbindet sie etwa Shopware 6 mit Odoo, ein CRM mit dem Newsletter-System oder eine App mit einem sicheren Backend. Falsch umgesetzt schafft sie neue Abhängigkeiten, schwer auffindbare Fehler und genau die Doppelpflege, die eigentlich verschwinden sollte.
API-Integration-Leitfaden: Erst den Prozess, dann die Schnittstelle
Der häufigste Fehler beginnt vor der ersten Codezeile: Teams sprechen über Systeme, nicht über Abläufe. „Der Shop soll ans ERP“ klingt klar, beantwortet aber keine entscheidende Frage. Welche Daten werden wann übertragen? Wer gilt bei widersprüchlichen Informationen als führendes System? Was passiert, wenn ein Datensatz unvollständig ist oder ein Zielsystem nicht erreichbar ist?
Nehmen wir einen B2B-Shop. Ein Kunde bestellt einen Artikel, dessen Preis von Kundengruppe, Menge und Vertragskonditionen abhängt. Die Bestellung soll ins ERP, der Lagerbestand zurück in den Shop und der Versandstatus an den Kunden. Hier reicht es nicht, Produkte irgendwie zu synchronisieren. Es muss feststehen, ob Preise im ERP oder im Shop gepflegt werden, ob Bestände in Echtzeit oder in Intervallen aktualisiert werden und wie Teillieferungen dargestellt werden.
Eine gute Integration beginnt daher mit einer Prozessaufnahme. Dabei werden die tatsächlichen Arbeitsschritte erfasst, nicht nur der gewünschte Zielzustand. Wo wird heute manuell korrigiert? Welche Excel-Datei dient als heimliche Referenz? Welche Ausnahme tritt regelmäßig auf? Gerade diese Ausnahmen entscheiden darüber, ob eine Schnittstelle im Alltag trägt oder nur in einer Präsentation gut aussieht.
Das führende System eindeutig bestimmen
Für jede Datenart braucht es eine klare Antwort auf die Frage: Wo liegt die Wahrheit? Ohne diese Entscheidung entstehen Konflikte fast zwangsläufig. Wenn Produktdaten gleichzeitig im ERP, im Shop und in einer PIM-Lösung geändert werden können, ist die nächste Überschreibung nur eine Frage der Zeit.
Typische Zuordnungen können so aussehen: Artikelstammdaten und Bestände liegen im ERP, redaktionelle Produkttexte und Erlebniswelten im Shop, Kundendaten im CRM und Zahlungsstatus beim Payment-Anbieter. Das ist kein allgemeingültiges Rezept. In manchen Unternehmen ist das PIM für Produktdaten führend, in anderen muss der Shop bestimmte lokale Inhalte verwalten. Entscheidend ist, dass die Regel dokumentiert, technisch umgesetzt und für die beteiligten Teams verständlich ist.
Auch bei Kundenkonten lohnt sich Genauigkeit. Soll ein neu registrierter Shopkunde sofort im ERP angelegt werden? Dürfen Vertrieb und Kunde dieselbe Adresse ändern? Wie werden Dubletten erkannt? Solche Fragen wirken klein, verursachen aber sonst falsche Rechnungen, nicht zustellbare Sendungen und unnötige Rückfragen.
Echtzeit ist nicht immer die bessere Wahl
Viele Anforderungen nennen „Echtzeit“, obwohl eigentlich Aktualität innerhalb eines sinnvollen Zeitfensters gemeint ist. Eine Bestandsänderung bei knapp verfügbaren Artikeln kann tatsächlich sofort in den Shop müssen. Ein nächtlicher Abgleich von Archivdaten dagegen spart Last, Kosten und Komplexität.
Grundsätzlich kommen drei Muster infrage. Beim Abruf fragt ein System Daten bei Bedarf aktiv ab. Das ist einfach nachzuvollziehen, kann bei vielen Anfragen aber das Quellsystem belasten. Beim zeitgesteuerten Abgleich werden Daten etwa alle fünf oder 15 Minuten übertragen. Das ist planbar, bringt jedoch eine Verzögerung mit sich. Ereignisbasierte Kommunikation übermittelt eine Änderung direkt, beispielsweise sobald eine Bestellung bezahlt wurde. Sie reagiert schnell, verlangt aber ein sauberes Fehler- und Wiederholungsmanagement.
In der Praxis ist oft eine Kombination sinnvoll. Der Shop erhält Bestandsänderungen ereignisbasiert, gleicht aber zusätzlich nachts den vollständigen Datenbestand ab. Dieser Abgleich ist kein Zeichen von Misstrauen gegenüber der Schnittstelle, sondern eine Absicherung gegen seltene Übertragungsfehler oder manuelle Korrekturen.
Fehlerfälle gehören zum Konzept, nicht ins Ticketsystem
APIs fallen aus. Zugangsdaten laufen ab. Ein ERP verarbeitet kurzzeitig keine neuen Aufträge. Ein Sonderzeichen in einer Adresse löst unerwartet einen Validierungsfehler aus. Wer eine Integration nur für den Erfolgsfall entwickelt, verlagert den Aufwand in den Betrieb.
Deshalb braucht jede Schnittstelle definierte Antworten auf drei Punkte: Was wird bei einem Fehler wiederholt, wann wird ein Vorgang endgültig abgebrochen und wer wird informiert? Eine Bestellung darf beispielsweise nicht doppelt ins ERP geschrieben werden, nur weil die Rückmeldung auf dem Übertragungsweg verloren ging. Technisch helfen eindeutige Vorgangskennungen, Protokolle und eine sogenannte Idempotenz: Derselbe Auftrag kann mehrfach eintreffen, wird aber nur einmal verarbeitet.
Ebenso wichtig ist eine nachvollziehbare Fehlerwarteschlange. Sie erlaubt es, fehlerhafte Datensätze gezielt zu prüfen und nach einer Korrektur erneut anzustoßen, statt alle Daten pauschal erneut zu senden. Für den Fachbereich sollte erkennbar sein, welcher Vorgang betroffen ist und was zu tun ist. Eine kryptische Fehlermeldung aus dem Quellcode hilft der Buchhaltung nicht weiter.
Sicherheit und Datenschutz von Anfang an mitplanen
Schnittstellen übertragen oft Kundendaten, Bestellungen, Gesundheitsdaten oder interne Konditionen. Sicherheitsfragen gehören damit in die Konzeption, nicht als letzter Prüfschritt vor dem Launch. Dazu zählen klar begrenzte Berechtigungen, sichere Authentifizierung, verschlüsselte Übertragungswege und der sparsame Umgang mit Daten.
Ein Shop muss für die Versandabwicklung beispielsweise keine vollständige Kundenhistorie an einen Logistikdienst übergeben. Eine App im Gesundheitsumfeld stellt nochmals höhere Anforderungen: Zugriffe müssen nachvollziehbar sein, Datenflüsse sauber dokumentiert und Rollen präzise getrennt. Welche Maßnahmen erforderlich sind, hängt vom Risiko, den Datenarten und den beteiligten Systemen ab.
Auch der Betrieb verdient Aufmerksamkeit. API-Schlüssel gehören nicht in Quellcode oder ungeschützte Tabellen. Sie müssen sicher verwaltet, bei Personalwechseln überprüft und regelmäßig erneuert werden können. Test- und Produktivzugänge bleiben getrennt. Das klingt selbstverständlich, wird unter Zeitdruck aber erstaunlich oft übergangen.
Testen mit echten Geschäftsfällen statt mit Musterdaten
Eine Integration gilt nicht als fertig, weil ein einzelner Testdatensatz angekommen ist. Entscheidend sind reale Prozessvarianten: unterschiedliche Steuersätze, Rabattregeln, Teillieferungen, Stornos, Gastbestellungen, Auslandadressen, Retouren oder mehrere Lagerorte. Je nach Geschäftsmodell kommen Freigabeprozesse, Kreditlimits oder kundenspezifische Sortimente hinzu.
Vor dem Go-Live sollten Fachbereich und Technik diese Fälle gemeinsam prüfen. Der Fachbereich erkennt, ob die Ergebnisse operativ nutzbar sind. Die Entwicklung kann nachvollziehen, ob Daten korrekt transformiert, Fehler sauber behandelt und Laufzeiten akzeptabel sind. Ein klarer Abnahmekatalog verhindert dabei Diskussionen nach dem Start.
Hilfreich ist außerdem ein kontrollierter Parallelbetrieb. Für eine begrenzte Zeit werden alte und neue Abläufe verglichen, ohne die tägliche Arbeit unnötig zu blockieren. Abweichungen fallen so auf, bevor sie Rechnungen, Lagerbewegungen oder Kundenkommunikation betreffen.
Betrieb und Weiterentwicklung fest einplanen
Eine API-Integration ist kein abgeschlossenes Bauprojekt. Shop- und ERP-Updates verändern Datenmodelle, Anbieter passen Endpunkte an und das Unternehmen entwickelt neue Prozesse. Wer dafür weder Verantwortlichkeiten noch Budget vorsieht, riskiert, dass eine anfangs gute Verbindung schleichend zum Problem wird.
Zum laufenden Betrieb gehören Monitoring, Protokollauswertung, Backups relevanter Konfigurationen und feste Reaktionswege bei Störungen. Sinnvolle Kennzahlen sind nicht nur technische Antwortzeiten. Auch die Zahl fehlgeschlagener Übertragungen, die Bearbeitungsdauer offener Fehler und die Quote manueller Nacharbeit zeigen, ob die Integration ihren Zweck erfüllt.
Bei größeren Landschaften kann eine Integrationsschicht sinnvoll sein. Sie entkoppelt Systeme und verhindert, dass jedes neue Tool direkt mit jedem bestehenden Tool verbunden wird. Das schafft mehr Ordnung, ist aber nicht automatisch die richtige Lösung. Bei zwei klar abgegrenzten Systemen kann eine direkte Schnittstelle wartbarer und wirtschaftlicher sein. Architektur sollte dem Geschäftsproblem folgen, nicht einem Techniktrend.
Eine tragfähige Integration erkennt man letztlich nicht an vielen Endpunkten oder besonders technischen Begriffen. Sie zeigt sich montagmorgens: Aufträge stimmen, Bestände sind nachvollziehbar, Teams arbeiten nicht mehr gegen Excel-Listen an und Änderungen lassen sich planbar umsetzen. Wer diese Grundlage sauber schafft, gewinnt nicht nur Datenfluss, sondern Zeit für das eigentliche Geschäft.