Eine Schnittstelle zu bauen ist der einfache Teil.

Zwei Systeme technisch zu verbinden dauert bei modernen Anwendungen oft weniger als einen Tag. Woran Integrationsprojekte in KMU scheitern, ist nie die Verbindung. Es sind die vier Fragen, die vorher niemand beantwortet hat: welche Felder wandern, welches System hat recht, wie oft, und was passiert, wenn die Leitung ausfaellt.

Dieser Beitrag geht die vier Fragen der Reihe nach durch – und die drei technischen Entscheidungen, die daran haengen.

Was eine Schnittstelle uebertraegt, ist keine technische Frage

Eine API ist eine definierte Stelle, an der zwei Programme miteinander reden. Sie legt fest, was abgefragt werden kann, wie die Anfrage aussehen muss und in welcher Form die Antwort kommt.

Was sie nicht festlegt: welche Daten du uebertragen willst. Das ist der Teil, den keine Dokumentation beantwortet.

Die haeufigste Fehlannahme ist, dass eine gute Integration moeglichst viel synchronisiert. Das Gegenteil trifft zu. Eine gute Integration uebertraegt genau die Felder, die auf der anderen Seite gebraucht werden – und keins mehr. Jedes zusaetzliche Feld ist ein Feld, das irgendwann in zwei Fassungen existiert.

Die Frage, die vor jeder Verbindung steht: wer fuehrt?

Wenn eine Kundenadresse im CRM und im ERP steht und beide geaendert werden koennen, gewinnt bei der naechsten Synchronisation eine von beiden. Welche, muss entschieden sein, bevor die Schnittstelle laeuft.

Ohne diese Entscheidung ueberschreibt das System abwechselnd die jeweils neuere Korrektur. Das faellt wochenlang nicht auf und ist danach kaum zu rekonstruieren.

Die Regel ist simpel und wird trotzdem meist uebergangen: Pro Datenfeld gibt es genau ein fuehrendes System. Nicht pro Anwendung – pro Feld. Die Adresse kann im CRM fuehren, der Lagerbestand im ERP, der Zahlungsstatus in der Buchhaltung.

Abfragen oder benachrichtigen lassen

Es gibt zwei Wege, wie ein System von einer Aenderung erfaehrt.

Beim Abfragen fragt System A in festen Abstaenden bei System B nach, ob sich etwas geaendert hat. Einfach zu bauen, und in 95 Prozent der Abfragen lautet die Antwort „nichts Neues".

Beim Webhook dreht sich die Richtung: System B meldet sich selbst, sobald etwas passiert. Ein neuer Kunde im CRM loest eine Nachricht aus, das angeschlossene System reagiert darauf.

Der Unterschied ist nicht nur Effizienz. Ein Webhook liefert die Aenderung in dem Moment, in dem sie passiert. Eine Abfrage im Stundenrhythmus liefert sie im Schnitt eine halbe Stunde spaeter.

Der Preis: Ein Webhook, der ins Leere laeuft, weil das Zielsystem gerade nicht antwortet, ist verloren – es sei denn, jemand hat einen Wiederholungsmechanismus gebaut. Das wird beim Bauen gern vergessen und faellt beim ersten Ausfall auf.

Echtzeit ist meistens die falsche Frage

„In Echtzeit" klingt in jedem Angebot gut und ist in den meisten Prozessen ueberfluessig.

Bei einem Lagerbestand zaehlt jede Minute: Wird ein Artikel verkauft, der bereits weg ist, entsteht ein Problem mit einem Kunden. Bei einer Adressaenderung reicht der naechste Morgen. Der Unterschied ist nicht technisch, sondern betriebswirtschaftlich – und deshalb kann ihn kein Dienstleister fuer dich entscheiden.

Die nuetzlichere Frage lautet: Was kostet es, wenn diese Information eine Stunde alt ist? Wenn die Antwort „nichts" ist, hast du gerade eine teure Anforderung gestrichen.

Eigene Schnittstelle, iPaaS oder Middleware

Drei Wege, und die Fachwelt ist sich uneins, welcher fuer kleine Betriebe richtig ist.

Die eigene Schnittstelle

Direkt programmiert, genau auf den Prozess zugeschnitten. Volle Kontrolle, keine laufende Lizenz. Dafuer traegt jemand die Wartung – und wenn ein Anbieter seine API aendert, ist das dein Problem.

iPaaS

Eine Plattform, die fertige Verbindungen zwischen bekannten Anwendungen mitbringt. Schnell eingerichtet, oft ohne Programmierung. Die Nachfrage ist messbar da, aber niedrig: 90 Suchen im Monat in der Schweiz, bei einer Schwierigkeit von 12 – ein Begriff, den Anbieter haeufiger verwenden als Kunden (Semrush, Datenbank Schweiz, September 2026).

Der Streit dreht sich um die Abrechnung. iPaaS-Anbieter rechnen meist pro Vorgang. Bei 200 Bestellungen im Monat ist das guenstig. Bei 20'000 kann dieselbe Verbindung mehr kosten als die Entwicklung, die sie ersetzen sollte. Wer dagegenhaelt, verweist auf die eingesparte Wartung – und das ist ein faires Argument.

Middleware

Eine Schicht dazwischen, die mehrere Systeme verbindet, statt jedes Paar einzeln zu verkabeln. Sie lohnt sich ab dem Punkt, an dem drei oder mehr Anwendungen zusammenspielen: Bei vier Systemen sind es bereits sechs moegliche Direktverbindungen, bei fuenf zehn.

Unsere Position, und sie ist eine Position, keine Messung: Unter drei Systemen ist eine eigene Schnittstelle fast immer der guenstigere Weg. Ab drei lohnt sich die Frage nach einer Schicht dazwischen. Ob iPaaS oder selbst gebaut, entscheidet die Mengenrechnung oben – nicht die Grundsatzfrage.

Was passiert, wenn die Schnittstelle ausfaellt

Sie wird ausfallen. Ein Anbieter wartet seine Server, ein Zertifikat laeuft ab, ein Feld heisst nach einem Update anders.

Die Frage ist nicht, ob, sondern was dann sichtbar wird. Drei Dinge gehoeren von Anfang an dazu:

  • Ein Wiederholungsversuch mit Abstand. Nicht sofort und nicht endlos – sonst verstaerkt der Wiederholungsversuch die Stoerung.
  • Eine Meldung an einen Menschen. Eine Schnittstelle, die still ausfaellt, faellt Wochen spaeter auf, wenn Zahlen nicht stimmen.
  • Ein Protokoll, das zeigt, was nicht angekommen ist. Ohne das bleibt nur, alles nochmals zu uebertragen.

Wer eine Integration in Betrieb nimmt, ohne diese drei Punkte, hat keine Integration gebaut, sondern eine Abhaengigkeit.

Sicherheit: drei Stellen, an denen es schiefgeht

Der Zugang selbst. Ein API-Schluessel ist ein Passwort mit Vollzugriff – er gehoert nicht in den Quellcode und nicht in eine Datei, die mit dem Projekt wandert. Mehr dazu unter IT-Security.

Der Umfang. Viele Anbieter geben Schluessel mit vollen Rechten aus, obwohl die Verbindung nur lesen muss. Ein Lesezugriff, der nichts aendern kann, richtet im Fall eines Lecks deutlich weniger Schaden an.

Der Datenumfang. Jedes Feld, das du uebertraegst, liegt danach an zwei Stellen. Bei Personendaten ist das eine Frage nach dem Datenschutzgesetz, nicht nur nach der Technik.

Datenmigration ist nicht Datenintegration

Zwei Dinge, die ständig verwechselt werden, weil beide „Daten von A nach B" bedeuten.

Eine Migration ist einmalig: Der Bestand zieht um, danach ist die Quelle tot. Eine Integration laeuft dauerhaft: Beide Systeme bleiben, beide arbeiten weiter.

Der Unterschied entscheidet ueber die Vorbereitung. Vor einer Migration bereinigt man den Bestand einmal. Vor einer Integration klaert man, welches System bei welchem Feld fuehrt – sonst wandern die Doppeleintraege einfach schneller hin und her. Woran man ein Datensilo ueberhaupt erkennt, steht in unserem Beitrag zu Datensilos zwischen ERP und CRM.

Wann es sich fuer ein KMU rechnet

Die Rechnung ist unromantisch. Nimm einen Vorgang, den heute jemand von Hand uebertraegt. Zaehle, wie oft er im Monat vorkommt, und schaetze die Minuten dafuer.

Zwanzig Bestellungen im Monat mal fuenf Minuten sind knapp zwei Stunden. Dafuer baut niemand eine Schnittstelle. Zweihundert Bestellungen mal fuenf Minuten sind mehr als zwei Arbeitstage – dort rechnet sich Automatisierung im ersten Quartal.

Der zweite, unterschaetzte Posten sind die Fehler. Manuelle Uebertragung erzeugt Tippfehler, und ein falscher Lagerbestand oder eine falsche Rechnungsadresse kostet mehr als die fuenf Minuten, die er gespart hat.

Die Schnittstelle automatisiert noch keinen Prozess

Eine Verbindung uebertraegt Daten. Sie entscheidet nicht, was danach passieren soll.

Das ist der Punkt, an dem viele Projekte auf halbem Weg stehen bleiben: Die Systeme reden, aber niemand hat festgelegt, welcher Ablauf daraus folgt. Der zweite Schritt gehoert zur Prozessautomatisierung – die Schnittstelle ist die Voraussetzung, nicht das Ergebnis.

Wie wir Systeme verbinden und was dabei entsteht, steht unter Integrationen. Wenn dabei eine eigene Anwendung noetig wird, ist das eine Frage fuer Web-Apps; laeuft die Verbindung dauerhaft im Betrieb, gehoert sie in einen Managed Service mit einem vereinbarten SLA.