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 ausfällt.
Dieser Beitrag geht die vier Fragen der Reihe nach durch – und die drei technischen Entscheidungen, die daran hängen.
Was eine Schnittstelle überträgt, 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 übertragen willst. Das ist der Teil, den keine Dokumentation beantwortet.
Die häufigste Fehlannahme ist, dass eine gute Integration möglichst viel synchronisiert. Das Gegenteil trifft zu. Eine gute Integration überträgt genau die Felder, die auf der anderen Seite gebraucht werden – und keins mehr. Jedes zusätzliche Feld ist ein Feld, das irgendwann in zwei Fassungen existiert.
Die Frage, die vor jeder Verbindung steht: wer führt?
Wenn eine Kundenadresse im CRM und im ERP steht und beide geändert werden können, gewinnt bei der nächsten Synchronisation eine von beiden. Welche, muss entschieden sein, bevor die Schnittstelle läuft.
Ohne diese Entscheidung überschreibt das System abwechselnd die jeweils neuere Korrektur. Das fällt wochenlang nicht auf und ist danach kaum zu rekonstruieren.
Die Regel ist simpel und wird trotzdem meist übergangen: Pro Datenfeld gibt es genau ein führendes System. Nicht pro Anwendung – pro Feld. Die Adresse kann im CRM führen, der Lagerbestand im ERP, der Zahlungsstatus in der Buchhaltung.
Abfragen oder benachrichtigen lassen
Es gibt zwei Wege, wie ein System von einer Änderung erfährt.
Beim Abfragen fragt System A in festen Abständen bei System B nach, ob sich etwas geändert 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 löst eine Nachricht aus, das angeschlossene System reagiert darauf.
Der Unterschied ist nicht nur Effizienz. Ein Webhook liefert die Änderung in dem Moment, in dem sie passiert. Eine Abfrage im Stundenrhythmus liefert sie im Schnitt eine halbe Stunde später.
Der Preis: Ein Webhook, der ins Leere läuft, weil das Zielsystem gerade nicht antwortet, ist verloren – es sei denn, jemand hat einen Wiederholungsmechanismus gebaut. Das wird beim Bauen gern vergessen und fällt beim ersten Ausfall auf.
Echtzeit ist meistens die falsche Frage
„In Echtzeit" klingt in jedem Angebot gut und ist in den meisten Prozessen überflüssig.
Bei einem Lagerbestand zählt jede Minute: Wird ein Artikel verkauft, der bereits weg ist, entsteht ein Problem mit einem Kunden. Bei einer Adressänderung reicht der nächste Morgen. Der Unterschied ist nicht technisch, sondern betriebswirtschaftlich – und deshalb kann ihn kein Dienstleister für dich entscheiden.
Die nützlichere 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 für kleine Betriebe richtig ist.
Die eigene Schnittstelle
Direkt programmiert, genau auf den Prozess zugeschnitten. Volle Kontrolle, keine laufende Lizenz. Dafür trägt jemand die Wartung – und wenn ein Anbieter seine API ändert, 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 häufiger 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 günstig. Bei 20'000 kann dieselbe Verbindung mehr kosten als die Entwicklung, die sie ersetzen sollte. Wer dagegenhält, 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 mögliche Direktverbindungen, bei fünf zehn.
Unsere Position, und sie ist eine Position, keine Messung: Unter drei Systemen ist eine eigene Schnittstelle fast immer der günstigere 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 ausfällt
Sie wird ausfallen. Ein Anbieter wartet seine Server, ein Zertifikat läuft ab, ein Feld heisst nach einem Update anders.
Die Frage ist nicht, ob, sondern was dann sichtbar wird. Drei Dinge gehören von Anfang an dazu:
- Ein Wiederholungsversuch mit Abstand. Nicht sofort und nicht endlos – sonst verstärkt der Wiederholungsversuch die Störung.
- Eine Meldung an einen Menschen. Eine Schnittstelle, die still ausfällt, fällt Wochen später auf, wenn Zahlen nicht stimmen.
- Ein Protokoll, das zeigt, was nicht angekommen ist. Ohne das bleibt nur, alles nochmals zu übertragen.
Wer eine Integration in Betrieb nimmt, ohne diese drei Punkte, hat keine Integration gebaut, sondern eine Abhängigkeit.
Sicherheit: drei Stellen, an denen es schiefgeht
Der Zugang selbst. Ein API-Schlüssel ist ein Passwort mit Vollzugriff – er gehört nicht in den Quellcode und nicht in eine Datei, die mit dem Projekt wandert. Mehr dazu unter IT-Security.
Der Umfang. Viele Anbieter geben Schlüssel mit vollen Rechten aus, obwohl die Verbindung nur lesen muss. Ein Lesezugriff, der nichts ändern kann, richtet im Fall eines Lecks deutlich weniger Schaden an.
Der Datenumfang. Jedes Feld, das du überträgst, 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 läuft dauerhaft: Beide Systeme bleiben, beide arbeiten weiter.
Der Unterschied entscheidet über die Vorbereitung. Vor einer Migration bereinigt man den Bestand einmal. Vor einer Integration klärt man, welches System bei welchem Feld führt – sonst wandern die Doppeleinträge einfach schneller hin und her. Woran man ein Datensilo überhaupt erkennt, steht in unserem Beitrag zu Datensilos zwischen ERP und CRM.
Wann es sich für ein KMU rechnet
Die Rechnung ist unromantisch. Nimm einen Vorgang, den heute jemand von Hand überträgt. Zähle, wie oft er im Monat vorkommt, und schätze die Minuten dafür.
Zwanzig Bestellungen im Monat mal fünf Minuten sind knapp zwei Stunden. Dafür baut niemand eine Schnittstelle. Zweihundert Bestellungen mal fünf Minuten sind mehr als zwei Arbeitstage – dort rechnet sich Automatisierung im ersten Quartal.
Der zweite, unterschätzte Posten sind die Fehler. Manuelle Übertragung erzeugt Tippfehler, und ein falscher Lagerbestand oder eine falsche Rechnungsadresse kostet mehr als die fünf Minuten, die er gespart hat.
Die Schnittstelle automatisiert noch keinen Prozess
Eine Verbindung überträgt 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 gehört 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 nötig wird, ist das eine Frage für Web-Apps; läuft die Verbindung dauerhaft im Betrieb, gehört sie in einen Managed Service mit einem vereinbarten SLA.