API-Integration: Systeme verbinden statt ersetzen

In den meisten Unternehmen existieren zahlreiche Softwaresysteme nebeneinander: ERP, CRM, Buchhaltung, Warenwirtschaft, Webshop, E-Mail-Marketing, Zeiterfassung. Das Problem: Diese Systeme sprechen oft nicht miteinander. Daten werden manuell übertragen, in Excel-Listen kopiert oder doppelt gepflegt. API-Integration löst genau dieses Problem – ohne bestehende Systeme ersetzen zu müssen.

Inhaltsverzeichnis

• Was ist API-Integration? 🔗
• Warum Systeme verbinden statt ersetzen? 🔄
• REST, GraphQL, Webhooks: Die wichtigsten Schnittstellentypen 🌐
• Integrationsmuster in der Praxis 🧩
• Praxisbeispiele: Wo API-Integration sofort Mehrwert bringt 🚀
• Adapter, Middleware und iPaaS: Die richtige Architektur wählen 🏗️
• Kein API vorhanden? Alternativen und Workarounds 🛠️
• Sicherheit bei API-Integrationen 🔒
• Datenqualität und Konsistenz ✅
• Kosten und Aufwand realistisch einschätzen 💰
• Typische Stolperfallen ⚠️
• Fahrplan: Von der Ist-Analyse zur laufenden Integration 🗺️
• Fazit: Verbinden ist das neue Ersetzen 🎯

Was ist API-Integration? 🔗

Eine API (Application Programming Interface) ist eine Schnittstelle, über die zwei Softwaresysteme miteinander kommunizieren können. API-Integration bedeutet, diese Schnittstellen zu nutzen, um Daten und Funktionen zwischen verschiedenen Anwendungen automatisch auszutauschen.

Ein einfaches Beispiel: Ein Online-Shop (Shopify, WooCommerce) meldet eine neue Bestellung über seine API an das Warenwirtschaftssystem. Dieses aktualisiert den Lagerbestand, erstellt einen Lieferschein und übergibt die Rechnung an die Buchhaltung – alles automatisch, ohne manuelles Eingreifen.

Was API-Integration nicht ist

• Kein Systemwechsel – bestehende Software bleibt erhalten
• Kein Großprojekt – oft reichen ein Adapter oder ein kleiner Service
• Keine Einbahnstraße – Daten können in beide Richtungen fließen

Warum Systeme verbinden statt ersetzen? 🔄

Die Alternative zur Integration wäre: Alle Systeme durch eine einzige Software ersetzen, die alles kann. Das klingt elegant, ist in der Praxis aber teuer, riskant und selten realistisch.

Gründe für Integration statt Ablösung

Der Best-of-Breed-Ansatz

Statt ein monolithisches System für alles zu erzwingen, wählt man für jeden Bereich das beste Werkzeug – und verbindet diese über APIs. Das Ergebnis: Jede Abteilung arbeitet mit dem optimalen Tool, und die Daten fließen trotzdem automatisch.

REST, GraphQL, Webhooks: Die wichtigsten Schnittstellentypen 🌐

REST-APIs

REST (Representational State Transfer) ist der verbreitetste API-Standard. Daten werden über HTTP-Methoden ausgetauscht:

• GET – Daten abrufen
• POST – Daten erstellen
• PUT/PATCH – Daten aktualisieren
• DELETE – Daten löschen

REST-APIs arbeiten typischerweise mit JSON als Datenformat und sind einfach zu verstehen, gut dokumentiert und weit verbreitet. Die meisten modernen Geschäftsanwendungen bieten REST-APIs an.

GraphQL

GraphQL ermöglicht es, mit einer einzigen Anfrage genau die Daten abzurufen, die man benötigt – nicht mehr und nicht weniger. Das reduziert den Datenverkehr und ist besonders nützlich, wenn man Daten aus mehreren Quellen in einer Abfrage zusammenführen möchte.

Webhooks

Webhooks funktionieren nach dem Push-Prinzip: Statt regelmäßig bei einem System nachzufragen, ob sich etwas geändert hat (Polling), sendet das Quellsystem aktiv eine Benachrichtigung, sobald ein Ereignis eintritt – z. B. „Neue Bestellung eingegangen” oder „Kunde hat bezahlt”.

SOAP

SOAP (Simple Object Access Protocol) ist ein älterer Standard, der noch häufig in Enterprise-Systemen, Behörden und Finanzanwendungen anzutreffen ist. SOAP verwendet XML und bietet strenge Typprüfung und eingebaute Sicherheitsmechanismen. Bei der Integration mit älteren Systemen kommt man an SOAP oft nicht vorbei.

Dateiaustausch (CSV, XML, EDI)

Nicht jedes System bietet eine API. Viele ältere Anwendungen exportieren und importieren Daten über Dateien – CSV, XML oder branchenspezifische Formate wie EDI (Electronic Data Interchange). Auch das lässt sich automatisieren: Ein Service überwacht einen Ordner, liest neue Dateien ein und verarbeitet sie weiter.

Integrationsmuster in der Praxis 🧩

Punkt-zu-Punkt-Integration

Zwei Systeme werden direkt miteinander verbunden. Einfach, schnell, gut geeignet für einzelne Integrationen. Bei vielen Systemen wird es jedoch schnell unübersichtlich – jede neue Verbindung erhöht die Komplexität.

Hub-and-Spoke (Middleware)

Alle Systeme kommunizieren über einen zentralen Hub. Neue Systeme werden nur an den Hub angebunden. Das reduziert die Anzahl der Verbindungen drastisch und macht die Architektur wartbar.

Event-Driven (Ereignisgesteuert)

Systeme reagieren auf Ereignisse: „Bestellung erstellt”, „Rechnung bezahlt”, „Lagerbestand unter Mindestmenge”. Über Message Broker wie RabbitMQ, Apache Kafka oder Redis Streams werden Ereignisse verteilt. Ideal für Echtzeit-Szenarien.

Batch-Integration

Daten werden in regelmäßigen Intervallen synchronisiert – z. B. jede Nacht alle neuen Bestellungen aus dem Shop ins ERP übertragen. Weniger komplex als Echtzeit, aber für viele Anwendungsfälle ausreichend.

Praxisbeispiele: Wo API-Integration sofort Mehrwert bringt 🚀

Shop & Warenwirtschaft 🛒

Problem: Online-Bestellungen werden manuell in das Warenwirtschaftssystem eingetragen. Lagerbestände stimmen nicht überein, Kunden bestellen Artikel, die bereits vergriffen sind.

Lösung: Ein Service synchronisiert Bestellungen, Lagerbestände und Versandstatus bidirektional zwischen Shop und Warenwirtschaft – in Echtzeit oder im 5-Minuten-Takt.

Ergebnis: Keine manuellen Eingaben, korrekte Bestände, automatisierte Versandbenachrichtigungen.

CRM & E-Mail-Marketing 📧

Problem: Neue Leads aus dem CRM werden manuell in Mailchimp/Brevo übertragen. Newsletter-Abmeldungen kommen nicht im CRM an.

Lösung: API-Integration synchronisiert Kontakte, Tags und Opt-in/Opt-out-Status zwischen CRM und E-Mail-Tool.

Ergebnis: Aktuelle Kontaktlisten, DSGVO-konforme Abmeldungen, zielgenaue Segmentierung ohne Handarbeit.

ERP & Buchhaltung 💳

Problem: Rechnungsdaten werden aus dem ERP exportiert, in Excel aufbereitet und dann im DATEV importiert. Fehleranfällig und zeitintensiv.

Lösung: Ein Adapter übergibt Rechnungsdaten automatisch im DATEV-Format an die Buchhaltung. Zahlungseingänge fließen zurück ins ERP.

Ergebnis: Tagesaktuelle Finanzdaten, weniger Buchungsfehler, Zeitersparnis in der Buchhaltung.

Zeiterfassung & Lohnabrechnung ⏱️

Problem: Arbeitszeiten werden in einem System erfasst, müssen aber für die Lohnabrechnung in ein anderes System übertragen werden.

Lösung: Monatlich werden die freigegebenen Stunden per API an das Abrechnungssystem übergeben – inklusive Zuschlägen, Abwesenheiten und Projektzuordnungen.

Ergebnis: Automatischer Datentransfer, weniger Nachfragen, pünktliche Abrechnung.

Ticketsystem & Monitoring 🔔

Problem: Monitoring-Benachrichtigungen (Server down, Festplatte voll) kommen per E-Mail – und gehen unter.

Lösung: Monitoring-Events werden per Webhook direkt als Tickets im Ticketsystem angelegt, mit Priorität, Kategorie und Zuständigkeit.

Ergebnis: Kein Ereignis wird übersehen, klare Zuständigkeiten, nachvollziehbare Bearbeitung.

Altsystem & moderne Anwendung 🔧

Problem: Ein bewährtes, aber älteres System (z. B. AS/400, Delphi-Anwendung, Access-Datenbank) hat keine API. Daten stecken fest.

Lösung: Ein Adapter liest Daten direkt aus der Datenbank des Altsystems, transformiert sie und stellt sie als REST-API bereit. Moderne Anwendungen greifen darüber auf die Daten zu.

Ergebnis: Das Altsystem bleibt im Einsatz, die Daten werden trotzdem nutzbar – ohne das gesamte System ablösen zu müssen.

Adapter, Middleware und iPaaS: Die richtige Architektur wählen 🏗️

Individueller Adapter

Ein kleiner, maßgeschneiderter Service, der zwei spezifische Systeme verbindet. Ideal, wenn eine einzelne Integration benötigt wird und keine Standardlösung passt.

Typischer Aufwand: 2–10 Personentage
Technologien: Python, Node.js, Go oder Java mit REST/HTTP-Bibliotheken

Middleware / Integration Platform

Eine zentrale Plattform, über die alle Systeme kommunizieren. Sinnvoll ab 5+ Integrationen oder wenn Transformationen, Routing und Monitoring benötigt werden.

Beispiele:

• Apache Camel – Open Source, hochflexibel, viele Konnektoren
• MuleSoft – Enterprise-Lösung mit API-Management
• WSO2 – Open-Source-Integrationsplattform

iPaaS (Integration Platform as a Service)

Cloud-basierte Integrationsplattformen, die ohne eigene Infrastruktur auskommen. Gut für Standardszenarien und wenn man schnell starten möchte.

Beispiele:

• n8n – Open Source, selbst hostbar, visueller Editor
• Make (Integromat) – Einsteigerfreundlich, viele Konnektoren
• Zapier – Einfachste Variante, für einfache Punkt-zu-Punkt-Verbindungen
• Microsoft Power Automate – Gut in Microsoft-Umgebungen integriert

Entscheidungshilfe

Kein API vorhanden? Alternativen und Workarounds 🛠️

Nicht jedes System bietet eine API. Gerade ältere oder spezialisierte Software hat oft keine dokumentierte Schnittstelle. Trotzdem gibt es Wege:

Datenbankzugriff

Wenn keine API existiert, die Datenbank aber zugänglich ist (MySQL, PostgreSQL, Microsoft SQL Server, Oracle), kann man Daten direkt lesen und schreiben. Risiko: Änderungen an der Datenbank können Seiteneffekte haben. Deshalb sollte man nur lesen und die Schreiblogik über die Anwendung selbst abwickeln – oder sehr genau wissen, was man tut.

Dateischnittstelle

Viele Systeme bieten CSV-/XML-Export und -Import. Ein automatisierter Service kann:

1. Exportdatei abrufen (z. B. per FTP, SFTP oder Dateisystemüberwachung)
2. Daten transformieren
3. In das Zielsystem importieren

Screen Scraping / RPA

Als letzter Ausweg: Ein Bot simuliert Benutzereingaben in der Oberfläche des Altsystems. Fragil und wartungsintensiv, aber manchmal die einzige Möglichkeit. Tools wie UiPath oder Automation Anywhere können das.

API selbst bauen

Wenn das Altsystem eine Datenbank hat, kann man eine REST-API davor setzen, die als Adapter fungiert. Das Altsystem bleibt unverändert, aber seine Daten werden über eine saubere Schnittstelle zugänglich.

Sicherheit bei API-Integrationen 🔒

Sobald Systeme miteinander kommunizieren, müssen Sicherheitsaspekte bedacht werden:

Authentifizierung und Autorisierung

• API Keys – Einfachste Methode, reicht für interne Integrationen
• OAuth 2.0 – Standard für sichere, tokenbasierte Authentifizierung
• Mutual TLS (mTLS) – Beide Seiten authentifizieren sich gegenseitig per Zertifikat

Transportverschlüsselung

Alle API-Aufrufe sollten über HTTPS (TLS) laufen. Unverschlüsselte HTTP-Verbindungen sind inakzeptabel, sobald Geschäftsdaten übertragen werden.

Zugriffsbeschränkung

• Least Privilege – Jede Integration erhält nur die Rechte, die sie tatsächlich braucht
• Rate Limiting – Maximale Anzahl an Anfragen pro Zeiteinheit begrenzen
• IP-Whitelisting – Zugriff nur von bekannten IP-Adressen erlauben

Logging und Monitoring

Jeder API-Aufruf sollte protokolliert werden: Wer hat wann welche Daten abgerufen oder verändert? Bei Anomalien (ungewöhnlich viele Anfragen, Fehler) sollte eine Benachrichtigung ausgelöst werden.

Datenqualität und Konsistenz ✅

Die häufigste Ursache für fehlgeschlagene Integrationen sind nicht technische Probleme, sondern Datenprobleme:

Daten-Mapping

Jedes System hat sein eigenes Datenmodell. Ein „Kunde” im CRM hat andere Felder als ein „Debitor” in der Buchhaltung. Vor der Integration muss ein klares Mapping definiert werden: Welches Feld entspricht welchem?

Dubletten und Konflikte

Was passiert, wenn derselbe Kunde in System A und System B existiert – mit unterschiedlichen Adressdaten? Es braucht klare Regeln: Wer ist die führende Quelle (Master)? Wie werden Konflikte aufgelöst?

Fehlerbehandlung

Was passiert, wenn ein API-Aufruf fehlschlägt? Robuste Integrationen haben:

• Retry-Logik – Fehlgeschlagene Aufrufe automatisch wiederholen
• Dead Letter Queue – Nicht zustellbare Nachrichten aufbewahren statt verwerfen
• Idempotenz – Mehrfach gesendete Nachrichten verursachen keine Dubletten

Kosten und Aufwand realistisch einschätzen 💰

Typische Kostenrahmen

Laufende Kosten

• iPaaS-Plattformen: 30–500 €/Monat (abhängig von Volumen)
• Eigene Middleware: Hosting + Wartung, ca. 100–500 €/Monat
• Individueller Adapter: Hosting minimal, Wartung bei Änderungen

Amortisation

Ein manueller Datenabgleich, der einen Mitarbeiter 2 Stunden pro Tag kostet:

• 2 Std. × 220 Arbeitstage × 40 €/Std. = 17.600 € pro Jahr
• Eine Integration für 5.000–10.000 € amortisiert sich in wenigen Monaten

Typische Stolperfallen ⚠️

„Wir machen mal eben eine Integration”

Ohne saubere Anforderungsanalyse und Daten-Mapping wird aus der schnellen Integration ein Dauerproblem. Auch ein kleines Projekt braucht einen klaren Scope.

Fehlende Dokumentation

APIs ohne oder mit veralteter Dokumentation kosten enorm viel Zeit. Vor Projektstart prüfen: Gibt es eine API-Dokumentation? Ist sie aktuell? Gibt es eine Sandbox zum Testen?

Versionsänderungen nicht beachten

APIs werden weiterentwickelt. Wenn der Anbieter Version 2 abschaltet und man noch Version 1 nutzt, bricht die Integration. Empfehlung: Versionierung beachten und regelmäßig prüfen.

Monitoring vergessen

Eine Integration ohne Überwachung funktioniert – bis sie nicht mehr funktioniert. Und dann merkt man es erst, wenn Kunden sich beschweren. Monitoring und Alerting sind Pflicht.

Datenschutz übersehen

Wenn personenbezogene Daten zwischen Systemen fließen, muss die DSGVO beachtet werden. Bei Cloud-Diensten: Auftragsverarbeitungsvertrag (AVV) prüfen. Bei Drittland-Transfers: angemessenes Schutzniveau sicherstellen.

Fahrplan: Von der Ist-Analyse zur laufenden Integration 🗺️

Phase 1: Ist-Analyse (1–2 Tage)

• Welche Systeme sind im Einsatz?
• Wo fließen Daten manuell zwischen Systemen?
• Welche APIs stehen zur Verfügung?
• Wo entstehen die größten Zeitfresser?

Phase 2: Konzept und Daten-Mapping (2–3 Tage)

• Welche Daten sollen fließen und in welche Richtung?
• Feld-Mapping: Welches Feld in System A entspricht welchem Feld in System B?
• Fehlerszenarien definieren: Was passiert bei Konflikten, Ausfällen, Datenlücken?
• Architekturentscheidung: Adapter, iPaaS oder Middleware?

Phase 3: Prototyp (3–5 Tage)

• Erste Integration mit Testdaten aufbauen
• Erfolgreichen Datenfluss demonstrieren
• Edge Cases testen (leere Felder, Sonderzeichen, große Datenmengen)

Phase 4: Produktivbetrieb (2–3 Tage)

• Integration mit echten Daten in Betrieb nehmen
• Monitoring und Alerting einrichten
• Dokumentation erstellen (Daten-Mapping, Fehlerbehandlung, Ansprechpartner)

Phase 5: Betrieb und Wartung (laufend)

• Regelmäßig prüfen: Laufen alle Integrationen fehlerfrei?
• API-Änderungen der Anbieter beobachten
• Bei neuen Anforderungen: bestehende Integration erweitern

Fazit: Verbinden ist das neue Ersetzen 🎯

Die Zeiten, in denen man für jede Anforderung ein komplett neues System einführen musste, sind vorbei. API-Integration ermöglicht es, bestehende Systeme smart zu verbinden und dabei das Beste aus jeder Software herauszuholen.

Die wichtigsten Erkenntnisse:

• Klein starten: Eine einzelne Integration (z. B. Shop ↔ Warenwirtschaft) bringt sofort messbaren Mehrwert.
• Bestehende Systeme nutzen: Mitarbeiter arbeiten weiter mit vertrauten Tools – die Daten fließen im Hintergrund.
• Architektur bewusst wählen: Adapter für einzelne Verbindungen, iPaaS für mehrere Standardintegrationen, Middleware für komplexe Szenarien.
• Sicherheit und Monitoring nicht vergessen: Jede Integration braucht Verschlüsselung, Zugriffsschutz und Überwachung.
• Daten vor Technik: Das Daten-Mapping entscheidet über Erfolg oder Misserfolg – nicht das Tool.

Ob ein einzelner Adapter zwischen zwei Systemen oder eine unternehmensweite Integrationsplattform – der erste Schritt ist immer derselbe: Herausfinden, wo Daten heute manuell fließen, und diesen Weg automatisieren.

Sie haben Systeme, die nicht miteinander sprechen? Lassen Sie uns in einem kostenlosen Erstgespräch herausfinden, wo eine Integration für Sie Sinn macht. Hinterlassen Sie mir gerne eine Nachricht.