API-Integrationen brauchen Fehlerbehandlung, Versionierung und klare Dokumentation. REST, GraphQL und Webhooks haben unterschiedliche Einsatzfelder. Wer keine Fehlertoleranzen plant, baut fragile Systeme.
Wenn Systeme sprechen — aber sich nicht verstehen
Der Wunsch ist verständlich: CRM, Webshop, Website und ERP sollen nahtlos zusammenarbeiten. Neue Kunden aus dem Shop landen automatisch im CRM, Lagerbestände synchronisieren sich in Echtzeit, und Bestellstatus-Updates erscheinen sofort im Kundenportal. Was in der Präsentation glatt klingt, ist in der Realität oft ein fragiles Konstrukt aus Schnittstellen, das bei jedem Update eines der beteiligten Systeme auseinanderfällt.
INREMA begleitet regelmäßig Projekte, bei denen Integrationen nachträglich stabilisiert werden müssen. Das Muster ist dabei erstaunlich gleichförmig: Die Verbindung zwischen zwei Systemen wurde aufgebaut, funktionierte beim Launch — und niemand hat sich Gedanken darüber gemacht, was passiert, wenn der externe Dienst kurz nicht erreichbar ist, wenn sich die API-Version ändert oder wenn die übertragenen Daten ein unerwartetes Format haben. Das Ergebnis: Datenverlust, doppelte Einträge oder Prozesse, die still stehenbleiben, ohne dass jemand eine Fehlermeldung bekommt.
Eine API-Integration ist keine einmalige technische Aufgabe — sie ist eine dauerhaft zu wartende Systemkomponente. Wer das unterschätzt, baut sich eine technische Schuld auf, die früher oder später fällig wird. Dieser Artikel erklärt, welche Integrations-Technologien wann sinnvoll sind, welche Fehler am häufigsten gemacht werden — und wie stabile Integrationen aussehen.
Eine API-Integration ist keine einmalige Implementierung — sie ist eine dauerhaft zu wartende Systemkomponente, die Fehlerszenarien von Anfang an einplanen muss.
REST, GraphQL, Webhooks, WebSockets: Was ist was?
Nicht jede Integrations-Technologie passt zu jedem Anwendungsfall. Die Wahl des falschen Ansatzes führt zu unnötigem Datenverkehr, zu Echtzeit-Problemen oder zu einer Architektur, die schwer zu warten ist.
REST (Representational State Transfer) ist der am weitesten verbreitete API-Standard. Er funktioniert nach einem einfachen Prinzip: Ein Client schickt eine HTTP-Anfrage an eine URL, der Server antwortet mit Daten — typischerweise im JSON-Format. REST ist gut dokumentiert, von nahezu allen Systemen unterstützt und für die meisten Integrationsfälle die richtige Wahl. Die Schwäche: Bei komplexen Abfragen muss der Client oft mehrere Anfragen hintereinander schicken, um alle benötigten Daten zu erhalten.
GraphQL löst genau dieses Problem. Der Client definiert selbst, welche Felder er benötigt — und bekommt in einer einzigen Anfrage genau diese Daten zurück. Das spart Datenvolumen und reduziert Latenz. GraphQL ist besonders dann sinnvoll, wenn viele verschiedene Client-Typen (Mobile App, Web, Partner-API) dieselben Daten in unterschiedlichen Formaten benötigen. Der Nachteil: Die Implementierung auf Server-Seite ist aufwendiger, und das Caching ist komplexer als bei REST.
Webhooks funktionieren umgekehrt: Statt dass der Client regelmäßig fragt 'Gibt es Neuigkeiten?', schickt der Server aktiv eine Benachrichtigung, sobald ein Ereignis eintritt. Ideal für Szenarien wie Zahlungsbestätigungen, neue Bestellungen oder CRM-Events. Wichtig: Webhooks brauchen eine zuverlässige Empfangsinfrastruktur mit Bestätigungs-Logik — sonst gehen Events im Fehlerfall verloren. WebSockets ermöglichen echte bidirektionale Echtzeit-Kommunikation, zum Beispiel für Live-Chats, Dashboards oder kollaborative Anwendungen. Sie sind der technisch aufwendigste Ansatz und lohnen sich nur wenn wirklich Echtzeit-Anforderungen bestehen.
Häufigste Fehler bei API-Integrationen im Mittelstand
- Keine Fehlerbehandlung: Was passiert wenn die externe API 30 Sekunden nicht antwortet? Ohne Timeout-Logik und Retry-Mechanismus hängt die eigene Anwendung oder verliert stillschweigend Daten.
- Keine API-Versionierung beachtet: Externe APIs ändern sich. Wer keine Versionsstrategie hat, bemerkt Breaking Changes erst wenn Produktionsprozesse ausfallen.
- Keine Authentifizierung oder unsichere Token-Verwaltung: API-Schlüssel im Quellcode, in Git-Repos oder in Log-Dateien sind ein ernstes Sicherheitsrisiko — und in der Praxis erschreckend häufig.
- Keine Dokumentation der Integration: Wenn der Entwickler das Unternehmen verlässt, ist die Integration eine Blackbox. Niemand weiß mehr, welche Felder gemappt werden, warum bestimmte Daten transformiert werden oder was beim Fehler X zu tun ist.
- Keine Überwachung und kein Alerting: Integrationen, die still fehlschlagen, sind die gefährlichsten. Ohne Monitoring weiß niemand, dass seit gestern keine Bestellungen mehr ins CRM übertragen wurden.
- Falsche Daten-Mapping-Annahmen: Wenn das CRM-System Namen als 'Vorname Nachname' und der Shop als 'Nachname, Vorname' speichert, entstehen ohne sorgfältiges Mapping Dubletten und fehlerhafte Datensätze.
- Keine Rate-Limiting-Behandlung: Viele APIs begrenzen die Anzahl der Anfragen pro Minute. Wer das ignoriert, riskiert geblockte Verbindungen in Lastspitzen.
- Synchrone statt asynchrone Verarbeitung: Wer den Benutzer auf die Antwort einer externen API warten lässt, liefert schlechte Performance — und hat keine Lösung wenn die externe API langsam ist.
Stabile API-Integrationen in 6 Schritten aufbauen
-
Integrations-Anforderungen vor der Implementierung dokumentieren
Welche Daten fließen von wo nach wo? In welche Richtung? Bei welchen Ereignissen? Wer ist für die externe API verantwortlich und wie ist der Support-Prozess bei Ausfällen? Diese Fragen müssen beantwortet sein, bevor eine einzige Zeile Code geschrieben wird — sonst entstehen Annahmen, die sich später als falsch herausstellen.
-
Fehlerszenarien von Anfang an einplanen
Was passiert bei einem API-Timeout? Was bei einem HTTP-500-Fehler? Was wenn die Datenstruktur nicht dem erwarteten Format entspricht? Jede dieser Situationen braucht eine definierte Reaktion — Retry-Logik, Fallback-Verhalten oder zumindest eine Fehlermeldung, die im Monitoring auftaucht. 'Das wird schon nicht passieren' ist keine Strategie.
-
API-Schlüssel sicher verwalten
API-Zugangsdaten gehören in Umgebungsvariablen oder einen sicheren Key-Store — niemals in den Quellcode, niemals in Git-Repositories, niemals in Log-Dateien. Zugriffsrechte sollten auf das Minimum beschränkt werden, das die Integration tatsächlich benötigt. Rotationszyklen für API-Schlüssel einplanen.
-
Asynchrone Verarbeitung für zeitkritische Prozesse nutzen
Wenn eine Bestellung im Shop eingeht und gleichzeitig ins CRM übertragen werden soll, sollte die CRM-Übertragung nicht synchron im selben Request stattfinden. Stattdessen: eine Queue-basierte Verarbeitung, die die Übertragung entkoppelt. So bleibt die Shop-Antwort schnell — und die CRM-Integration kann im Hintergrund mit Retry-Logik arbeiten.
-
Monitoring und Alerting von Tag eins
Jede Integration braucht Logs, die im Fehlerfall Details liefern, und ein Monitoring-System, das bei wiederholten Fehlern aktiv benachrichtigt. Bei INREMA-Projekten wird ein automatischer Alarm ausgelöst, wenn eine Integration mehr als drei Fehler in Folge produziert — damit der Fehler nicht erst nach Tagen auffällt.
-
Änderungen der externen API beobachten
Provider-Ankündigungen zu API-Deprecations abonnieren, Changelog-Feeds verfolgen und API-Versionsnummern explizit in der Konfiguration verwalten. So ist bei einer neuen API-Version klar, welche Integrationen aktualisiert werden müssen — bevor die alte Version abgeschaltet wird.
Praxisbeispiel: Die stille Integration
CRM, ERP und Shop im Mittelstand: Typische Integrations-Szenarien
Im Mittelstand sind API-Integrationen keine Ausnahme mehr — sie sind Standard. Die häufigsten Szenarien, die INREMA umsetzt: Shop-zu-CRM-Synchronisation (neue Kunden, Bestellhistorie, Kundenstatus), ERP-zu-Shop-Produktdaten (Bestände, Preise, Produktinformationen), Website-Kontaktformulare zu CRM (automatische Lead-Anlage), Buchhaltungssysteme zu Shop (Rechnungsstellung, Steuerinformationen) und externe Dienste wie Versanddienstleister, Zahlungsanbieter oder Marketing-Automation-Tools.
Jede dieser Integrationen hat ihre eigenen Tücken. Shop-zu-ERP-Verbindungen müssen Bestandsreservierungen in Echtzeit abbilden — zu langsame Synchronisation führt zu Überverkäufen. Buchhaltungsintegrationen sind besonders kritisch, weil Fehler hier direkte steuerliche Konsequenzen haben können. Marketing-Automation-Anbindungen müssen DSGVO-konform gestaltet werden — welche Daten dürfen übertragen werden, welche nicht?
INREMA empfiehlt, jede neue Integrations-Anforderung zunächst mit einem Integrations-Diagramm zu dokumentieren: Welches System ist Master für welche Daten? Wer überschreibt wen im Konfliktfall? Wie oft soll synchronisiert werden — ereignisgesteuert oder im Batch? Diese Fragen frühzeitig zu klären, verhindert die häufigsten Probleme.
INREMA-Empfehlung: Middleware statt Direktverbindung
- REST, GraphQL, Webhooks und WebSockets haben unterschiedliche Stärken — die Wahl hängt vom konkreten Anwendungsfall ab, nicht vom Trend.
- Fehlerbehandlung, Retry-Logik und Monitoring sind keine optionalen Features — sie sind der Unterschied zwischen einer stabilen und einer fragilen Integration.
- API-Schlüssel gehören niemals in den Quellcode; Integrationen brauchen Dokumentation und Versionsbewusstsein.
- Eine Middleware-Schicht vereinfacht komplexe Integrationslandschaften und macht sie wartbarer.
Sie wollen CRM, Shop oder ERP verbinden — oder haben eine bestehende Integration, die immer wieder Probleme macht? INREMA analysiert Ihre Systemlandschaft und baut stabile, dokumentierte Schnittstellen.
API-Integration besprechenHäufige Fragen
Was ist der Unterschied zwischen REST und GraphQL?
Was sind Webhooks und wann sollte man sie verwenden?
Warum schlägt meine API-Integration nach Updates fehl?
Wie schütze ich API-Schlüssel in meiner Anwendung?
War dieser Artikel hilfreich?