API-Schnittstelle: wie Systeme Daten automatisch austauschen

Eine API-Schnittstelle ist ein definierter Zugang, über den zwei Programme Daten austauschen, ohne dass ein Mensch exportiert, kopiert oder nachträgt. Der Anbieter legt fest, welche Daten abrufbar sind, in welchem Format sie kommen und wer sie abrufen darf. Eine Integration verbindet auf dieser Grundlage Shop, CRM und Buchhaltung zu einem Ablauf.

API-Schnittstelle: Definition und Abgrenzung

API steht für Application Programming Interface, also für die Programmierschnittstelle eines Systems. Sie ist ein Vertrag zwischen zwei Programmen: Welche Anfragen sind erlaubt, welche Felder kommen zurück, welche Fehler sind vorgesehen. Solange dieser Vertrag eingehalten wird, kann jede Seite ihre Software intern umbauen, ohne die andere zu stören.

Davon zu unterscheiden ist der Datenimport per Datei. Ein nächtlicher CSV-Export ist eine Notlösung: Er kennt keinen Zeitpunkt der Änderung, keine Rückmeldung über Fehler und keine Rechteprüfung. Er ist dort sinnvoll, wo ein Altsystem nichts anderes anbietet – und genau dann meist der erste Kandidat für eine Legacy-Modernisierung.

REST, Webhooks und Dateiübergabe

In Unternehmensprojekten treten vier Muster fast immer auf:

• REST über HTTPS. Der verbreitete Standard: Datenobjekte werden über feste Adressen angesprochen, Antworten kommen als JSON. Gut lesbar, gut testbar, von jedem Werkzeug unterstützt.
• Webhooks. Das Quellsystem meldet ein Ereignis aktiv, sobald es eintritt – eine Bestellung, eine Statusänderung. Das spart das ständige Nachfragen und liefert Daten sekundengenau.
• Warteschlangen. Nachrichten werden zwischengespeichert und nacheinander verarbeitet. Sinnvoll, wenn Lastspitzen auftreten oder ein Zielsystem zeitweise nicht erreichbar ist.
• Datei- oder Datenbankübergabe. Der Rückfallweg für ältere Systeme, mit klar definiertem Ablageort, Namensschema und Quittung.

Welches Muster passt, entscheidet meist das schwächere der beiden Systeme, nicht das stärkere.

Beispiele aus Shop, CRM und Buchhaltung

Drei Abläufe, die in mittelständischen Unternehmen regelmäßig von Hand laufen und sich anbinden lassen:

• Bestellung bis Rechnung. Der Shop meldet eine Bestellung, das CRM legt Vorgang und Kontakt an, die Buchhaltung erhält die Rechnungsdaten, der Versanddienst liefert die Sendungsnummer zurück.
• Stammdaten in einer Richtung. Artikel, Preise und Bestände haben ein führendes System; alle anderen lesen von dort und schreiben nicht zurück.
• Belege aus Fremdportalen. In einem anonymisierten Projekt haben wir 3 048 Rechnungen aus einem staatlichen E-Rechnungssystem automatisch abgeholt (Stand September 2026); beim ersten Abgleich der nachgeholten 2 408 Belege fehlten 346 davon im bis dahin manuell gepflegten Export – der Unterschied fiel erst durch den Abgleich auf.

Bausteine einer belastbaren API-Schnittstelle

Eine Anbindung, die im Alltag trägt, besteht aus mehr als einem Aufruf:

• Feldzuordnung. Welches Feld entspricht welchem, wie werden Datumsformate, Währungen, Steuersätze und Einheiten umgerechnet.
• Eindeutige Schlüssel. Jeder Datensatz braucht eine stabile Kennung auf beiden Seiten, sonst entstehen Dubletten.
• Wiederholbarkeit. Derselbe Aufruf zweimal ausgeführt darf nicht zwei Datensätze erzeugen.
• Fehlerbehandlung. Wiederholversuche mit wachsendem Abstand, eine Ablage für endgültig gescheiterte Vorgänge und eine Benachrichtigung an einen zuständigen Menschen.
• Protokoll. Nachvollziehbar muss bleiben, welcher Datensatz wann übertragen wurde – für Prüfungen und für die Fehlersuche. Ablage und Auswertung solcher Protokolle gehören in die Datenbank, siehe PostgreSQL für Unternehmensanwendungen.

Wo Anbindungen scheitern

Die häufigsten Ursachen sind nicht technischer, sondern fachlicher Natur. Erstens ungeklärte Führung: Zwei Systeme dürfen dasselbe Feld schreiben, und niemand weiß, welcher Wert gilt. Zweitens fehlende Testumgebung – wer nur im Echtsystem testen kann, testet zu wenig. Drittens Datenqualität: Unterschiedliche Schreibweisen desselben Lieferanten erzeugen Dubletten, die erst nach Monaten auffallen. Viertens fehlende Zuständigkeit für den Betrieb: Eine Anbindung, die niemanden benachrichtigt, wenn sie stillsteht, fällt erst durch fehlende Zahlen auf.

Ebenso unterschätzt wird die Vertragsseite der Gegenstelle: Zugangsdaten, Nutzungsgrenzen, Kündigungsfristen und Ankündigungen von Versionswechseln gehören vor dem Start geprüft.

Ein oft übersehener Punkt ist die Versionierung. Ändert der Anbieter Felder oder Bedeutungen, muss die eigene Seite das erkennen, bevor Kunden es merken. Bewährt haben sich ein automatischer Prüflauf gegen die Testumgebung der Gegenstelle und eine Benachrichtigung, sobald Antworten von der erwarteten Struktur abweichen.

Wie wir ein Integrationsprojekt schneiden

Wir beginnen mit einer Bestandsaufnahme der Systeme, ihrer Zugänge und der Datenqualität, beschreiben danach je Datenfluss Richtung, Auslöser, Feldzuordnung und Prüfregel und setzen die Flüsse einzeln um – jeder mit eigenen Abnahmekriterien und einem Abgleich gegen das Quellsystem. Betrieb und Überwachung gehören zur Lieferung, nicht zur Kür. Welche Arbeiten dazugehören, steht auf der Seite Integrationen.