Wie Schnittstellen getrennte Systeme miteinander reden lassen

Vier Systeme, die nichts voneinander wissen

In vielen Unternehmen läuft der Online-Shop in einem Programm, die Kundenpflege im CRM, die Rechnungen in der Buchhaltung und der Versand bei einem Dienstleister. Jedes Werkzeug erfüllt seinen Zweck. Das Problem entsteht an den Grenzen dazwischen.

Eine Bestellung kommt im Shop an. Jemand tippt die Kundendaten ins CRM, legt die Rechnung in der Buchhaltung an und erfasst den Versandauftrag im vierten Tool. Vier Programme, dieselben Daten, vier Mal abgetippt. Das kostet Zeit und produziert Tippfehler, die sich später als falsche Lieferadresse oder falscher Rechnungsbetrag rächen.

Genau diese Lücke schließen Schnittstellen. Sie lassen Programme direkt miteinander reden, sodass eine Bestellung einmal entsteht und von allein durch die Kette wandert.

Was eine API wirklich ist

API steht für Application Programming Interface, also Programmierschnittstelle. Hinter dem sperrigen Wort steckt eine einfache Idee. Eine API ist eine vereinbarte Sprache, über die zwei Programme miteinander sprechen.

Eine API ist die Speisekarte eines Restaurants. Sie legt fest, was bestellt werden kann und was zurückkommt, ohne dass der Gast die Küche betreten muss.

Der Gast (das eine Programm) liest die Karte, gibt eine Bestellung auf und bekommt ein definiertes Ergebnis. Wie die Küche (das andere Programm) intern arbeitet, bleibt verborgen und ist auch nicht wichtig. Wichtig ist nur, dass die Bestellung in einer Form erfolgt, die beide Seiten verstehen.

Die meisten modernen Schnittstellen im Web sprechen über HTTP, dasselbe Protokoll, über das auch der Browser Seiten lädt. Eine Anfrage besteht aus einer Adresse, einer Methode und meist einem Datenpaket. Die folgende Tabelle zeigt die vier Grundoperationen.

JSON, das Format hinter dem Austausch

Damit zwei Programme Daten verstehen, brauchen sie ein gemeinsames Format. Im Web hat sich JSON durchgesetzt, kurz für JavaScript Object Notation. Es ist Text, den sowohl Maschinen schnell verarbeiten als auch Menschen lesen können.

JSON beschreibt Daten als Paare aus Schlüssel und Wert. Eine Bestellung könnte so aussehen.

{
  "bestellnummer": "2025-4471",
  "kunde": "Beispiel GmbH",
  "betrag_netto": 1290.00,
  "waehrung": "EUR",
  "positionen": 3,
  "bezahlt": true
}

Jede Zeile ist eindeutig. betrag_netto ist eine Zahl, bezahlt ein Wahrheitswert, kunde ein Text. Genau diese Klarheit erlaubt es der Buchhaltung, den Betrag korrekt zu übernehmen, ohne ihn zu interpretieren. Das ältere Format XML leistet Ähnliches, ist aber deutlich gesprächiger und in modernen Web-Schnittstellen seltener geworden.

Webhooks, wenn das System selbst Bescheid sagt

Bei einer klassischen API fragt ein Programm aktiv nach, ob es etwas Neues gibt. Es ruft die Schnittstelle in regelmäßigen Abständen auf und prüft den Stand. Dieses Verfahren heißt Polling. Es funktioniert, verschwendet aber Anfragen, denn die meisten Abfragen liefern die Antwort, dass sich nichts geändert hat.

Webhooks drehen das Prinzip um. Statt zu fragen, wird man benachrichtigt. Sobald ein Ereignis eintritt, etwa eine erfolgreiche Zahlung, schickt das auslösende System von sich aus ein Datenpaket an eine hinterlegte Adresse. Der Empfänger reagiert sofort, ohne vorher gefragt zu haben.

Der Unterschied lässt sich an Zahlen festmachen. Wer alle fünf Minuten pollt, erzeugt rund 288 Anfragen pro Tag, von denen die allermeisten leer ausgehen. Ein Webhook feuert nur dann, wenn wirklich etwas passiert, also vielleicht zwölf Mal am selben Tag. Weniger Last, frischere Daten.

• Polling fragt aktiv und in festem Takt nach, unabhängig davon, ob es Neues gibt.
• Ein Webhook meldet sich nur beim tatsächlichen Ereignis und liefert Daten näher in Echtzeit.
• Polling ist robust, wenn der Empfänger nicht dauerhaft erreichbar ist, Webhooks brauchen einen verlässlich erreichbaren Endpunkt.

Fehlerfälle und warum Idempotenz zählt

Schnittstellen laufen über Netzwerke, und Netzwerke fallen aus. Eine Anfrage geht raus, die Antwort kommt nicht zurück, obwohl die Bestellung in Wahrheit längst verbucht wurde. Sendet das System die Anfrage nun erneut, droht eine doppelte Bestellung.

Hier setzt Idempotenz an. Eine idempotente Schnittstelle erkennt eine wiederholte Anfrage und führt sie kein zweites Mal aus. Üblich ist ein Idempotenz-Schlüssel, eine eindeutige Kennung, die das sendende System mitschickt. Trifft derselbe Schlüssel zweimal ein, antwortet der Empfänger mit dem Ergebnis des ersten Versuchs, statt einen neuen Vorgang anzulegen.

Mindestens so wichtig ist der richtige Umgang mit Antwort-Codes. HTTP liefert sie als dreistellige Zahlen.

Ein 400er ist ein Fehler auf der eigenen Seite und wird durch Wiederholen nicht besser. Ein 500er oder 429er ist oft vorübergehend, hier hilft ein erneuter Versuch mit wachsendem Abstand, das sogenannte exponentielle Backoff. Wer beides sauber trennt und mit Idempotenz absichert, baut eine Kette, die einen kurzen Ausfall übersteht, ohne Schaden anzurichten.

Der Nutzen, wenn Daten von allein fließen

Eine angebundene Kette verändert den Arbeitsalltag spürbar. Die Bestellung entsteht einmal im Shop. Von dort wandert der Kunde ins CRM, der Betrag in die Buchhaltung und der Auftrag zum Versand, ohne dass jemand etwas abtippt. Was vorher mehrere Minuten manuelle Übertragung pro Bestellung kostete, läuft in Sekunden und ohne Tippfehler.

Das senkt nicht nur den Aufwand, sondern auch die Fehlerquote. Eine Lieferadresse, die nur einmal erfasst wird, kann nicht beim dritten Abtippen verrutschen. Daten, die automatisch fließen, sind außerdem aktueller, weil niemand auf den nächsten freien Moment wartet, um sie zu übertragen.

Wer personenbezogene Daten zwischen Systemen überträgt, braucht eine Rechtsgrundlage nach Art. 6 DSGVO, im Geschäftskontext meist die Vertragserfüllung. Schnittstellen sollten nur die Felder übergeben, die der Zweck wirklich verlangt, und die Übertragung verschlüsselt über HTTPS laufen. Datensparsamkeit ist hier kein Hindernis, sondern saubere Technik.

Eine solche Anbindung lässt sich nicht aus dem Stand bestellen. Sie beginnt damit, die Systeme und ihre Datenflüsse zu verstehen, bevor die erste Zeile entsteht. Diese Reihenfolge, erst verstehen, dann planen, dann umsetzen, dann erweitern, ist der rote Faden hinter allem, was wir bauen, und auf der Seite Mission ausführlich beschrieben.

Fazit

Eine API ist keine Magie, sondern eine vereinbarte Sprache zwischen Programmen. Webhooks liefern Ereignisse näher in Echtzeit, JSON hält die Daten klar und lesbar, und Idempotenz sorgt dafür, dass ein abgebrochener Versuch keinen doppelten Schaden anrichtet. Zusammen lösen diese Bausteine das Grundproblem getrennter Systeme. Daten werden nicht mehr von Hand übertragen, sie fließen.

---

Laufen Shop, CRM, Buchhaltung und Versand noch getrennt? Wir schauen uns die Datenflüsse an und zeigen, welche Schnittstelle den größten Handgriff spart.