API-Integrationen für ERP, CRM und E-Commerce-Systeme

API-Integrationen für ERP, CRM und E-Commerce verbinden die Systeme, mit denen Ihr Unternehmen ohnehin arbeitet, sodass Aufträge, Kunden, Preise, Bestände und Rechnungen ohne manuelles Abtippen fließen. Entscheidend ist dabei weniger die einzelne Schnittstelle als die Architektur dahinter: eine klare Datenhoheit pro Objekt, eine Warteschlange, die Ausfälle abfängt, wiederholbare Schreibvorgänge ohne Dubletten und ein Protokoll, in dem auch die Fachabteilung nachvollziehen kann, was mit einem Auftrag passiert ist. Im Folgenden zeigen wir, wie wir solche Integrationen aufbauen und worauf Sie vor dem Projektstart achten sollten.

Die typische Ausgangslage im Mittelstand

In vielen mittelständischen Unternehmen ist die Systemlandschaft über Jahre gewachsen. Häufig finden wir:

• ein ERP-System – etwa SAP Business One, Microsoft Dynamics 365 Business Central, weclapp, JTL-Wawi oder eine Branchenlösung, oft noch On-Premise,
• ein CRM für Vertrieb und Angebotswesen,
• einen oder mehrere Vertriebskanäle wie Onlineshop, B2B-Kundenportal oder Marktplätze,
• ergänzende Werkzeuge für PIM, Lager, Versand, Zahlungen und Buchhaltung, zum Beispiel die Übergabe an DATEV.

Zwischen diesen Systemen werden Daten heute oft per CSV-Export, E-Mail oder schlicht per Hand übertragen. Das funktioniert, bis das Volumen steigt oder ein Mitarbeiter im Urlaub ist.

Zuerst klären: Welches System ist führend?

Bevor eine Zeile Code entsteht, muss für jedes Datenobjekt feststehen, welches System die maßgebliche Quelle ist. Ohne diese Regel überschreiben sich Systeme gegenseitig, und niemand weiß, welcher Wert stimmt. Eine bewährte Aufteilung:

• Artikelstamm: ERP oder PIM → Shop, Portal, CRM.
• Marketingtexte und Bilder: PIM → Shop und Portal.
• Preise, Staffeln und Kundenkonditionen: ERP → alle Vertriebskanäle.
• Bestände: ERP oder Lagerverwaltung → Shop und Portal.
• Kundenstamm: ERP, mit Abgleich zum CRM; Neukunden erst nach Freigabe.
• Leads und Verkaufschancen: CRM, Übergabe an das ERP bei Auftrag.
• Aufträge: Shop oder Portal → ERP.
• Rechnungen und Lieferstatus: ERP → Portal und CRM.

Diese Aufteilung gehört in die Projektdokumentation und sollte mit den Fachbereichen abgestimmt sein – nicht nur mit der IT.

Architektur: eine eigene Integrationsschicht

Für alles, was über einen einfachen Export hinausgeht, empfehlen wir eine eigenständige Integrationsschicht statt vieler Plugins in Shop und ERP. Wir setzen dafür meist Laravel ein; die Details beschreiben wir auf der Seite Laravel API-Integrationen. Die Bausteine:

• Konnektoren je System, die dessen REST-, SOAP- oder OData-Schnittstelle kapseln. Wo es keine API gibt, auch Dateiaustausch oder lesende Datenbank-Views.
• Warteschlange mit Laravel Queues und Redis: Jeder Auftrag ist ein Job mit Status, Wiederholungszähler und Historie.
• Mapping-Schicht für Artikelnummern, Einheiten, Steuerschlüssel, Währungen und Statuscodes – konfigurierbar, nicht fest im Code.
• Geplante Aufgaben für periodische Abgleiche, etwa einen nächtlichen Bestandsabgleich.
• Webhooks, sofern das Quellsystem sie anbietet, mit Signaturprüfung.
• Betriebsoberfläche, in der Mitarbeitende einen Auftrag suchen, jeden Schritt sehen und fehlgeschlagene Jobs erneut anstoßen können.

Der Vorteil: Ist das ERP wegen Wartung nicht erreichbar, nimmt der Shop weiter Bestellungen an. Sie warten in der Queue und werden übertragen, sobald die Verbindung wieder steht.

Beispiel: Auftrag vom Kundenportal ins ERP

1. Der Kunde bestellt im B2B-Kundenportal; das Portal speichert den Auftrag und löst ein Ereignis aus.
2. Die Integrationsschicht erstellt einen Job und nutzt die Portal-Auftragsnummer als Idempotenzschlüssel.
3. Der Job ordnet den Kunden dem Debitor im ERP zu, rechnet Verpackungseinheiten in Basiseinheiten um und setzt die richtigen Steuerschlüssel.
4. Der Konnektor legt den Kundenauftrag im ERP an. Bei einem Fehler wird mit wachsendem Abstand erneut versucht; nach dem letzten Versuch gibt es eine Benachrichtigung.
5. Die ERP-Auftragsnummer wird an das Portal zurückgemeldet.
6. Lieferschein, Rechnung und Status laufen später auf dem umgekehrten Weg zurück.

Durch den Idempotenzschlüssel entsteht bei einer Wiederholung nach einem Timeout kein doppelter Auftrag – einer der häufigsten und teuersten Integrationsfehler.

Was die Schnittstellen der Systeme hergeben

Nicht jede Schnittstelle deckt alle Prozesse ab. Microsoft Dynamics 365 Business Central bietet beispielsweise REST-APIs auf Basis von OData, SAP Business One den Service Layer. Ältere oder stark angepasste Systeme stellen oft nur Teilbereiche bereit, etwa Artikel und Aufträge, aber keine Kundenkonditionen. Prüfen Sie deshalb vor der Planung für jede Datenstrecke:

• Gibt es lesenden und schreibenden Zugriff auf das benötigte Objekt?
• Werden Änderungen per Webhook gemeldet oder muss periodisch abgefragt werden?
• Welche Limits gelten für Anfragen und Datenmengen?
• Ist eine Testumgebung mit realistischen Daten verfügbar?

Die Antworten bestimmen, ob eine Strecke in Echtzeit, im Minutentakt oder nächtlich läuft – und wie aufwendig sie wird.

E-Rechnung als zusätzlicher Treiber

Seit dem 1. Januar 2025 müssen Unternehmen in Deutschland im inländischen B2B-Geschäft E-Rechnungen empfangen können; die Pflicht zum Versand wird in Übergangsschritten bis 2028 eingeführt. Für viele Mittelständler ist das ein guter Anlass, die Rechnungsstrecke zu prüfen: Erzeugt das ERP bereits strukturierte Formate wie XRechnung oder ZUGFeRD? Wie werden eingehende E-Rechnungen verarbeitet und an die Buchhaltung übergeben? Die Integrationsschicht kann hier eingehende Dokumente annehmen, validieren und weiterleiten – die steuerliche Beurteilung im Einzelfall bleibt Sache Ihrer Steuerberatung.

Sicherheit und Datenschutz

• Authentifizierung über OAuth 2.0 oder eng begrenzte API-Tokens, keine geteilten Admin-Zugänge.
• Zugangsdaten in der Umgebungskonfiguration oder einem Secrets-Manager, nie im Repository.
• Minimale Rechte je Konnektor: Wer nur Bestände liest, darf keine Kunden löschen.
• Protokollierung von Anfragen, aber mit Maskierung personenbezogener Daten im Sinne der DSGVO.
• Bei On-Premise-ERP baut ein kleiner Agent im Firmennetz ausgehende HTTPS-Verbindungen auf, sodass keine eingehenden Ports geöffnet werden müssen.

Typische Fehler

• Direktes Schreiben in die ERP-Datenbank. Das umgeht Nummernkreise, Reservierungen und Steuerlogik und kann nach dem nächsten Update brechen.
• Kein Abgleich. Auch ereignisgesteuerte Integrationen driften. Ein regelmäßiger Vergleich von Beständen und offenen Aufträgen deckt stille Lücken auf.
• Rate Limits ignoriert. Viele Cloud-APIs begrenzen Anfragen pro Minute. Massenupdates brauchen Batches und Wartezeiten.
• Keine fachliche Verantwortung. Jemand muss entscheiden, was mit einem Auftrag über dem Kreditlimit oder mit unbekanntem Artikel geschieht.

Standard-Connector oder individuelle Lösung?

Fertige Konnektoren und iPaaS-Plattformen eignen sich, wenn beide Systeme verbreitete Cloud-Produkte sind und der Prozess dem Standard entspricht. Eine individuelle Integrationsschicht lohnt sich bei On-Premise- oder stark angepassten ERP-Systemen, komplexen Preisregeln, mehreren Vertriebskanälen oder hohen Anforderungen an Nachvollziehbarkeit. Oft ist eine Kombination sinnvoll: Standard für einfache Strecken, individuell für den Kernprozess vom Auftrag bis zur Rechnung.

Vorgehen in Etappen

1. Bestandsaufnahme: Systeme, Versionen, verfügbare Schnittstellen, Datenverantwortliche, Mengen.
2. Lesende Phase: Daten aus dem führenden System übernehmen und mit dem heutigen Stand vergleichen.
3. Erster Schreibprozess: meist Aufträge ins ERP, zunächst mit manueller Freigabe.
4. Rückkanäle: Status, Rechnungen, Bestände.
5. Betrieb: Monitoring, Alarme, Betriebshandbuch und Übergabe an Ihr Team.

Wie ein Kundenportal auf eine solche Schicht aufsetzt, beschreiben wir im Beitrag B2B-Kundenportal mit Laravel und Vue.js. Für Freigaben, Benachrichtigungen und wiederkehrende Aufgaben rund um die Integration lesen Sie Prozessautomatisierung für B2B-Unternehmen mit API-Workflows.

Nächster Schritt

Wählen Sie einen Prozess, bei dem Ihr Team heute Daten zwischen zwei Systemen überträgt, und notieren Sie die beteiligten Systeme, deren Versionen und das ungefähre tägliche Volumen. Das genügt für eine erste technische Einschätzung. Mehr zu unseren API-Integrationen und Automatisierung finden Sie auf der Leistungsseite, oder Sie nehmen direkt Kontakt auf.