Schnittstelle und API erklärt: Was Ihr IT-Dienstleister meint

Im Projektgespräch fällt das Wort „Schnittstelle” in der ersten Viertelstunde mindestens zehnmal. Die Leiterin der Fachabteilung meint damit: „Die Zahlen sollen automatisch ins andere System kommen.” Der IT-Dienstleister versteht: „Wir brauchen eine REST-API mit Authentifizierung.” Und der Geschäftsführer denkt an einen Export, den früher jemand jeden Freitag von Hand gemacht hat. Alle drei nicken, alle drei sagen „Schnittstelle” und keiner meint dasselbe. Dieser Artikel hält die Begriffe auseinander: Schnittstelle und API einfach erklärt.

Das ist kein Kommunikationsfehler im Einzelfall. „Schnittstelle” ist ein Sammelbegriff für sehr unterschiedliche Wege, wie zwei Systeme Daten austauschen. Jeder dieser Wege hat andere Stärken, einen anderen Aufwand und andere Risiken. Wer die Unterschiede kennt, versteht Angebote besser, stellt die richtigen Rückfragen und trifft Entscheidungen, die später nicht teuer korrigiert werden müssen.

Dieser Artikel erklärt die vier häufigsten Wege ohne Fachjargon: API, Webhook, Datei-Austausch und die direkte Datenbankanbindung. Er führt durch ein Alltagsbild, das Sie jederzeit im Gespräch verwenden können, vergleicht die Wege in einer Tabelle und endet mit einer Liste von Fragen, die Sie bei jeder Anbindung stellen sollten. Technisches Vorwissen brauchen Sie nicht.

Schnittstelle und API erklärt: Was sie grundsätzlich ist

Eine Schnittstelle ist eine vereinbarte Stelle, an der zwei Systeme miteinander sprechen. Das klingt abstrakt, deshalb hilft ein Bild aus dem Restaurant. Sie sitzen am Tisch und die Küche steht für das System, das Daten besitzt oder verarbeitet. Sie selbst sind das andere System, das etwas braucht. Zwischen Ihnen und der Küche gibt es Regeln: Sie bestellen anhand einer Speisekarte, die Bedienung nimmt die Bestellung auf und bringt das Essen. Sie gehen nicht selbst in die Küche, öffnen Schränke und kochen mit.

Genau darin liegt der Kern jeder Schnittstelle. Sie legt fest, was man anfragen darf, in welcher Form und was man dafür zurückbekommt. Die Küche muss nicht verraten, wie sie intern arbeitet, und der Gast muss es nicht wissen. Beide Seiten können sich verändern, solange die Speisekarte und der Ablauf der Bestellung gleich bleiben. Das ist der größte praktische Vorteil: Systeme bleiben austauschbar und unabhängig voneinander, solange die Schnittstelle stabil ist.

Wo eine Schnittstelle fehlt, entsteht Handarbeit. Jemand liest eine Zahl aus Programm A ab und tippt sie in Programm B ein. Dieser Mensch ist dann die Schnittstelle, mit allen bekannten Nachteilen: Es dauert, es passieren Tippfehler und es hängt an der Verfügbarkeit einer einzelnen Person. Die Leistungsseite zu Schnittstellen und Systemanbindung beschreibt, wie wir solche Lücken systematisch schließen. Hier geht es zunächst darum, die Begriffe zu sortieren.

API: Anfrage und Antwort

Die API (Application Programming Interface) ist der bekannteste Weg und entspricht im Restaurantbild der Bestellung bei der Bedienung. Ein System stellt eine Anfrage, das andere antwortet. „Gib mir alle offenen Aufträge von heute.” Antwort: eine Liste. „Lege einen neuen Kunden mit diesen Angaben an.” Antwort: eine Bestätigung oder eine Fehlermeldung.

Die meisten APIs, mit denen Sie im Geschäftsalltag zu tun haben, arbeiten über dieselbe Grundlage wie das Web. Die Entwicklerdokumentation von Mozilla beschreibt das Protokoll HTTP als Client-Server-Protokoll, bei dem Anfragen vom Empfänger ausgehen, im Browser-Fall also von dem Programm, das etwas abrufen will. Die Gegenseite, der Server, antwortet auf jede Anfrage einzeln. Wichtig für das Verständnis: Die Initiative liegt immer beim Anfragenden. Der Server meldet sich nicht von allein.

Oft hören Sie in diesem Zusammenhang das Wort REST. Es bezeichnet einen verbreiteten Gestaltungsstil für solche Web-APIs, bei dem Daten über klar benannte Adressen abgefragt und verändert werden. Eine kompakte Erklärung finden Sie im Glossareintrag zur REST-API. Für Ihre Entscheidungen müssen Sie den Begriff nicht vertiefen. Es genügt zu wissen, dass „REST-API” in der Regel „Anfrage und Antwort über das Web” bedeutet und dass sich damit sehr viele moderne Systeme ansprechen lassen.

Stärken: Die Daten sind aktuell, weil sie im Moment der Anfrage geholt werden. Der Umfang lässt sich genau steuern, man holt nur, was man braucht. Und es lässt sich nachvollziehen, wer wann was angefragt hat. Schwächen: Das anfragende System muss wissen, wann es fragen soll. Wer nur alle zehn Minuten nachsieht, merkt Änderungen mit Verzögerung. Wer jede Sekunde nachsieht, belastet das andere System unnötig. Außerdem setzt eine API voraus, dass das Zielsystem überhaupt eine anbietet und dass sie die benötigten Funktionen abdeckt. Bei älteren Programmen ist das nicht selbstverständlich.

Webhook: Das System meldet sich von selbst

Stellen Sie sich vor, Sie müssten im Restaurant alle fünf Minuten die Bedienung fragen, ob Ihr Essen fertig ist. Das wäre mühsam für beide Seiten. Angenehmer ist der Summer, den manche Lokale ausgeben: Sobald das Essen bereit ist, meldet er sich. Das ist ein Webhook.

Technisch heißt das: Ein System schickt selbstständig eine Nachricht an eine vorher vereinbarte Adresse, sobald etwas Bestimmtes passiert. Ein Auftrag wurde angelegt, eine Zahlung ist eingegangen, ein Status hat sich geändert. Das empfangende System muss nicht nachfragen, es wird informiert. Im Glossar steht die Begriffsklärung zu Webhooks und auch Werkzeuge für Workflow-Automatisierung nutzen sie häufig als Startpunkt eines Ablaufs.

Der Gegensatz zur API-Anfrage ist wichtig, weil er in Gesprächen oft verwischt wird. Bei der API fragen Sie, bei einem Webhook werden Sie benachrichtigt. Webhooks eignen sich deshalb, wenn schnelle Reaktion wichtig ist und Änderungen unregelmäßig auftreten. Wenn ein Kunde eine Bestellung abschickt, soll der Ablauf im Hintergrund sofort starten und nicht erst beim nächsten Abfrage-Intervall.

Die Schwäche liegt an einer anderen Stelle. Ein Webhook ist eine einmalige Nachricht. Ist das empfangende System in diesem Moment nicht erreichbar, weil es gerade neu startet oder gewartet wird, kann die Nachricht verloren gehen, sofern der Absender sie nicht erneut versucht. Wer Webhooks produktiv nutzt, braucht daher eine Antwort auf die Frage: Was passiert, wenn die Nachricht nicht ankommt? Gute Lösungen sehen Wiederholungen vor oder gleichen regelmäßig per API ab, ob etwas übersehen wurde. Diese Kombination aus schneller Benachrichtigung und gelegentlichem Abgleich ist in der Praxis sehr verbreitet.

Datei-Austausch: unscheinbar und oft richtig

Der dritte Weg wirkt am wenigsten modern und ist trotzdem häufig die vernünftigste Wahl: Ein System schreibt eine Datei, ein anderes liest sie. Typische Formate sind CSV, eine Tabelle als reiner Text mit Trennzeichen und XML, ein strukturiertes Textformat. Die Datei wird in einen Ordner gelegt, per Mail verschickt oder auf einen Server hochgeladen und das andere System holt sie ab und verarbeitet sie.

Im Restaurantbild ist das der Zettel mit der Tagesbestellung für den Lieferanten, der jeden Morgen um sieben abgegeben wird. Es geht nicht um Sekunden, sondern um Zuverlässigkeit und Nachvollziehbarkeit. Die Datei ist ein Beleg: Sie können sie öffnen, prüfen, aufbewahren und im Zweifel erneut einspielen.

Wann passt das? Zum Beispiel, wenn ein älteres System keine API anbietet, aber Exporte schreiben kann. Oder wenn größere Datenmengen nur einmal pro Tag benötigt werden, etwa für den Abgleich der Artikelstammdaten. Oder wenn die Gegenseite ein externer Partner ist, der ohnehin einen festen Dateiaustausch pflegt. Viele Anbindungen an Buchhaltung, Lohnabrechnung oder Banken laufen aus guten Gründen seit Jahren über Dateien.

Die Nachteile sind ebenso klar. Die Daten sind immer so alt wie die letzte Datei. Das Format muss exakt stimmen: Eine zusätzliche Spalte, ein anderes Datumsformat oder ein Sonderzeichen im falschen Feld kann den Import stoppen oder, schlimmer, unbemerkt falsche Werte erzeugen. Und jemand muss sich darum kümmern, dass die Datei wirklich ankommt. Eine geplante Übertragung ohne Überwachung fällt erst auf, wenn Montag früh die Zahlen fehlen. Wer einen Datei-Austausch betreibt, sollte also immer festlegen, wer informiert wird, wenn an einem Tag keine Datei eintrifft.

Direkte Datenbankanbindung: meist die schlechteste Wahl

Der vierte Weg taucht in Gesprächen gern als Abkürzung auf: „Wir greifen einfach direkt auf die Datenbank zu.” Im Restaurantbild bedeutet das, dass der Gast durch die Küchentür geht und sich selbst aus dem Kühlschrank bedient. Es geht schnell, solange es funktioniert, und es ist aus mehreren Gründen riskant.

Erstens kennt das Fremdsystem seine Datenbank besser als jeder Außenstehende. Es speichert Werte so, wie es sie intern braucht, mit Sonderfällen, Statuscodes und Verknüpfungen, die nirgends erklärt sind. Wer von außen liest, interpretiert vieles falsch. Wer von außen schreibt, kann Datensätze erzeugen, die das Programm später nicht mehr versteht, ohne dass es eine Fehlermeldung gibt.

Zweitens ist die Anbindung fragil. Bringt der Hersteller ein Update heraus, ändert sich unter Umständen die interne Struktur und Ihre Anbindung bricht, obwohl nach außen alles gleich aussieht. Eine API oder ein Dateiformat sind dagegen Zusagen, die ein Hersteller bewusst stabil hält, weil er weiß, dass andere darauf bauen.

Drittens hat der Hersteller oft Vorgaben, was an seiner Datenbank verändert werden darf. Ein direkter Schreibzugriff kann Support- oder Wartungszusagen berühren. Prüfen Sie das im Vertrag, bevor Sie diesen Weg wählen. Lesender Zugriff auf eine eigens bereitgestellte Kopie der Daten, etwa für Auswertungen, ist ein anderer Fall und kann sinnvoll sein. Für die laufende Verarbeitung von Aufträgen, Rechnungen oder Kundendaten gilt jedoch: Fragen Sie zuerst, ob es einen offiziellen Weg gibt. Meist gibt es ihn.

Die vier Wege im Vergleich

Die Unterschiede lassen sich in einer Übersicht zusammenfassen. Die Bewertungen beschreiben typische Fälle und keine festen Regeln, denn jede konkrete Anbindung hat ihre Besonderheiten.

Zwei Dinge fallen auf. Erstens gibt es kein „bestes” Verfahren, sondern passende für unterschiedliche Aufgaben. Zweitens werden die Wege in der Praxis kombiniert: Ein Webhook löst den Ablauf aus, eine API holt die Details und am Ende landet eine Datei im Archiv. Wer das weiß, versteht auch, warum ein Angebot für „eine Schnittstelle” in Wirklichkeit mehrere Bausteine enthalten kann.

Wie Sie den passenden Weg auswählen

Die Wahl beginnt nicht bei der Technik, sondern bei drei Fragen an den Prozess. Die erste lautet: Wie schnell muss die Information ankommen? Wenn es genügt, dass die Daten am nächsten Morgen vorliegen, ist ein Datei-Austausch oder eine nächtliche Abfrage völlig ausreichend und meist einfacher zu betreiben. Wenn ein Kunde im Moment der Bestellung eine Bestätigung erwartet, brauchen Sie eine schnelle Variante wie Webhook oder direkte API-Anfrage.

Die zweite Frage lautet: Was bietet das Zielsystem überhaupt an? Hier entscheidet sich vieles. Ein modernes Programm mit gut dokumentierter API eröffnet Möglichkeiten, ein älteres System mit reinem Datei-Export setzt Grenzen. Fragen Sie den Hersteller konkret nach den vorhandenen Anbindungswegen und lassen Sie sich die Dokumentation zeigen, statt sich auf Aussagen wie „Das geht alles” zu verlassen. Gerade bei älteren Branchenlösungen lohnt der Blick, ob zusätzliche Module oder Lizenzen für den Zugriff nötig sind, denn das ist ein häufiger Kostenpunkt, der im ersten Angebot fehlt.

Die dritte Frage lautet: Was passiert, wenn es einmal nicht klappt? Ein Prozess, der nachts läuft und bei Ausfall nur eine E-Mail an eine ungelesene Adresse schickt, ist kein verlässlicher Prozess. Je geschäftskritischer der Datenfluss, desto wichtiger sind Wiederholungen, Protokolle und eine benannte Person, die Fehlermeldungen sieht.

Aus den Antworten ergibt sich in den meisten Fällen eine klare Empfehlung. Sie müssen sie nicht selbst technisch umsetzen, aber Sie können im Gespräch mit Dienstleistern prüfen, ob deren Vorschlag zu Ihren Antworten passt. Wie solche Anbindungen in automatisierte Abläufe eingebettet werden, zeigt der Beitrag über n8n-Beratung für den Mittelstand. Eine Einordnung, welche Prozesse sich überhaupt für Automatisierung eignen, bietet Prozessautomatisierung: Was Unternehmen im Mittelstand wirklich brauchen.

Fünf Fragen, die Sie bei jeder Anbindung stellen sollten

Egal welchen Weg Ihr Dienstleister vorschlägt: Mit diesen fünf Fragen finden Sie heraus, ob die Anbindung später im Betrieb trägt oder nur in der Vorführung gut aussieht.

Was passiert im Fehlerfall?

Jede Schnittstelle fällt irgendwann aus. Das Zielsystem ist wegen Wartung nicht erreichbar, ein Zugang läuft ab oder eine Nachricht ist fehlerhaft aufgebaut. Fragen Sie, wer davon erfährt, wie schnell und was mit den betroffenen Daten geschieht. Gute Antworten nennen automatische Wiederholungen, ein Fehlerprotokoll und eine Benachrichtigung an eine Person oder ein Postfach, das tatsächlich gelesen wird. Schlechte Antworten klingen nach „Das kommt eigentlich nicht vor”.

Was passiert, wenn sich eine Seite ändert?

Systeme werden aktualisiert. Eine neue Version des Fremdsystems kann Felder umbenennen oder Abläufe verändern. Fragen Sie, wie solche Änderungen erkannt werden und wer für Anpassungen zuständig ist. Besonders bei Anbindungen an externe Dienste ist das wichtig, weil Sie dort den Zeitpunkt der Änderung nicht selbst bestimmen. Hilfreich ist, wenn der Dienstleister Versionen der Schnittstelle benennt und angekündigte Änderungen des Herstellers verfolgt.

Wer ist zuständig und wie wird es dokumentiert?

Eine Schnittstelle, die nur eine Person versteht, ist ein Risiko, das in keiner Bilanz steht. Verlangen Sie eine Dokumentation, die erklärt, welche Daten in welche Richtung fließen, wann das geschieht und wie Zugangsdaten verwaltet werden. Klären Sie außerdem, wer nach der Einführung den Betrieb übernimmt, intern oder extern und was dafür vereinbart ist.

Wie werden Zugangsdaten und Berechtigungen behandelt?

Eine Schnittstelle bekommt Rechte in beiden Systemen. Fragen Sie, welche Rechte sie genau hat und ob sie auf das Nötige beschränkt sind. Eine Anbindung, die nur Aufträge lesen soll, braucht keinen Schreibzugriff auf Kundenstammdaten. Fragen Sie auch, wo Passwörter und Schlüssel liegen und wie sie erneuert werden, wenn jemand das Unternehmen verlässt. Bei personenbezogenen Daten sollte außerdem die Datenschutzbeauftragte oder der Datenschutzbeauftragte früh einbezogen werden, damit der Datenfluss dokumentiert und geprüft ist.

Lässt sich die Anbindung testen, ohne echte Daten zu gefährden?

Gute Anbindungen werden zuerst in einer Testumgebung oder mit Beispieldaten geprüft, bevor sie mit echten Kundendaten arbeiten. Fragen Sie, wie das geplant ist und wer die Ergebnisse abnimmt. Ein Probelauf im Parallelbetrieb, bei dem die alte Handarbeit noch eine Weile mitläuft und die Ergebnisse verglichen werden, ist bei geschäftskritischen Abläufen eine bewährte Absicherung.

Typische Missverständnisse im Gespräch

Zum Abschluss einige Sätze, die in Projektgesprächen häufig fallen und genauer hingehört werden sollten.

„Das ist ja nur eine kleine Schnittstelle” sagt wenig über den Aufwand aus. Der Umfang hängt weniger von der Zahl der Felder ab als von den Sonderfällen: Was geschieht bei doppelten Datensätzen, bei fehlenden Angaben, bei Änderungen nach der Übertragung? Fragen Sie nach diesen Fällen, sie machen den größeren Teil der Arbeit aus.

„Wir machen das in Echtzeit” klingt gut, ist aber nicht immer nötig. Prüfen Sie, ob der Prozess wirklich Sekunden verlangt oder ob eine Aktualisierung alle fünfzehn Minuten reicht. Der Unterschied kann sich im Aufwand und im Betrieb deutlich zeigen, weil Echtzeit mehr Absicherung gegen Ausfälle verlangt.

„Das System hat eine API” ist keine Garantie, dass sich Ihre Aufgabe damit lösen lässt. APIs decken oft nur einen Teil der Funktionen ab. Ob genau die Daten und Aktionen, die Sie brauchen, dabei sind, zeigt erst ein Blick in die Dokumentation oder ein kurzer technischer Test.

„Wir brauchen eine Standardschnittstelle” ist ebenfalls ein Satz, den man hinterfragen darf. Standardschnittstellen sparen Arbeit, wenn sie zu Ihrem Ablauf passen. Weicht Ihr Prozess ab, entsteht schnell eine Mischung aus Standard und Sonderlösung, die schwerer zu pflegen ist als eine von Anfang an passend gebaute Anbindung. Eine Prozessbeschreibung vor dem Schnittstellenentwurf verhindert das und genau deshalb sprechen wir bei Projekten zuerst über den Ablauf und erst dann über Technik. Wie dieser Zusammenhang aussieht, beschreibt auch die Leistungsseite zur Workflow-Automatisierung.

Wer die Begriffe sicher einordnen kann, führt die Gespräche selbstbewusster. Die erste Rückfrage lautet dann nicht mehr „Können Sie das anbinden?”, sondern „Auf welchem Weg, mit welcher Aktualität und mit welchem Verhalten im Fehlerfall?” Allein diese Frage trennt in vielen Angebotsgesprächen sehr schnell solide Vorschläge von vagen. Eine ausführliche Beschreibung des Grundprinzips der Systemverbindung finden Sie im Glossar unter API-Integration.

Ihr nächster Schritt

Nehmen Sie ein Papier und zeichnen Sie Ihre Systeme als Kästen. Verbinden Sie jedes Paar, zwischen dem heute Daten fließen, mit einem Strich. Schreiben Sie an jeden Strich, wie die Daten tatsächlich wandern: automatisch per API, per Datei, per Webhook oder durch einen Menschen, der abtippt oder kopiert. Markieren Sie die Striche, an denen ein Mensch sitzt.

Meistens zeigen sich nach fünfzehn Minuten zwei oder drei Stellen, an denen Handarbeit regelmäßig Zeit kostet und Fehler erzeugt. Das sind Ihre ersten Kandidaten für eine Anbindung. Für jede dieser Stellen können Sie nun die drei Fragen von oben beantworten: Wie schnell muss es gehen, was bietet die Gegenseite an und was soll bei einem Fehler passieren? Damit gehen Sie vorbereitet in das Gespräch mit Ihrem Dienstleister und können Vorschläge nicht nur anhören, sondern prüfen.

Quellen

Die technische Einordnung von HTTP als Client-Server-Protokoll, bei dem Anfragen vom Empfänger ausgehen, stützt sich auf die Dokumentation von Mozilla, Stand der Prüfung Oktober 2026:

MDN Web Docs: Overview of HTTP.

Die Beispiele im Restaurantbild sowie die Einschätzungen zu Aufwand und Fehlerquellen sind Erfahrungswerte aus der Projektarbeit und keine statistisch belegten Angaben.

Transparenzhinweis: Bei der Erstellung dieses Beitrags kam KI-Unterstützung zum Einsatz.