API-Integration & Daten-Synchronisation
Zwei Systeme tauschen Daten aus, ohne dass jemand sie abtippt – Feld für Feld festgelegt, mit einer klaren Regel, welche Seite gewinnt. Was sich nicht sauber übertragen lässt, landet nicht halbfertig im Zielsystem, sondern mit Ursache in einer Fehlerliste.
Die Schnittstelle ist selten das Schwierige
Fast jedes System hat heute eine Schnittstelle. Trotzdem tippt in vielen Betrieben jemand dieselbe Adresse in das CRM und ein zweites Mal in die Warenwirtschaft. Der Grund liegt selten an der Technik: Die beiden Systeme meinen mit „Kunde“ nicht dasselbe. Im CRM steht eine Adresse, in der Warenwirtschaft eine Rechnungs- und eine Lieferadresse. Der Shop kennt das Land als „DE“, das ERP als „DEU“. Und die Zahlungsart heißt an der einen Stelle „Rechnung“, an der anderen „Zahlungsziel 30 Tage netto“.
Die eigentliche Schwierigkeit beginnt danach, bei einer Frage, die technisch klingt und fachlich ist: Welches System darf ein Feld ändern? Solange Daten nur in eine Richtung fließen, ist das einfach. Sobald beide Seiten schreiben dürfen, braucht jedes einzelne Feld eine Regel – sonst überschreibt der nächtliche Abgleich die Telefonnummer, die der Vertrieb morgens korrigiert hat, und am Abend darauf schreibt die Gegenseite sie wieder zurück. Diese Regel steht in keinem Handbuch. Sie muss zwischen Vertrieb, Buchhaltung und IT ausgehandelt und dann aufgeschrieben werden – Feld für Feld, nicht System für System.
Das dritte Thema ist das unangenehmste: was passiert, wenn es schiefgeht. Eine Strecke, die mehrere hundert Datensätze am Tag überträgt, scheitert irgendwann – weil das Zielsystem im Wartungsfenster ist, weil ein Pflichtfeld leer bleibt, weil ein Anbieter die Zahl der Aufrufe begrenzt. Scheitert sie still, ist der Schaden größer als die Handarbeit davor: Niemand merkt es, und Wochen später fehlen im Zielsystem Aufträge, die längst ausgeliefert sind. Deshalb besteht der sichtbare Teil unserer Arbeit aus drei Dingen: der Feldtabelle, dem Wiederholungspfad und der Liste, in der steht, was nicht durchgekommen ist.
Welche Strecken sich lohnen
Wir starten mit der Strecke, die am häufigsten läuft und die klarste Datenhoheit hat. Weitere Objekte teilen sich später dieselbe Fehler- und Protokolllogik.
CRM und Warenwirtschaft abgleichen
Kunde, Ansprechpartner und Auftragsstatus stehen in beiden Systemen. Wer welches Feld ändern darf, steht vorher fest – je Feld, nicht nach Gefühl.
Shop und Warenwirtschaft verbinden
Bestellung hinein, Bestand und Sendungsnummer zurück – ausgelöst im Moment der Änderung statt durch einen nächtlichen Komplettabgleich.
Belege an die Buchhaltung übergeben
Rechnungen, Zahlungen und Kontierung an DATEV oder Ihr Rechnungswesen, mit einem Prüfschritt vor der Übergabe statt danach.
Altsysteme ohne Schnittstelle anbinden
Wenn nur ein Datenbankzugriff, ein Dateiexport oder ein SFTP-Ordner übrig bleibt, bauen wir den Adapter davor und behandeln ihn wie eine API.
Ereignisse statt nächtlicher Läufe
Ein Webhook meldet die Änderung beim Speichern; der Zeitplan bleibt nur als Netz darunter, falls eine Meldung verloren geht.
Fehlerstrecke und Protokoll
Jeder Datensatz, der nicht durchgeht, bekommt Ursache, Nutzdaten und eine zuständige Person – statt in einer Protokolldatei zu verschwinden.
Das Feld-Mapping, Zeile für Zeile
Ein Ausschnitt aus einer echten Abstimmung: links das Quellfeld im Shop, rechts das Zielfeld in der Warenwirtschaft, dazwischen die Regel. Sieben Felder, zwei davon laufen nicht durch. Darunter steht der Weg, den ein Datensatz nimmt, der scheitert.
| Quellfeld | Regel | Zielfeld |
|---|---|---|
| order.orderNumberText, 12 Zeichen | läuft1:1 übernommen | AuftragNrText, 20 Zeichen |
| customer.emailText, eindeutig | läuftSchlüssel für die Zuordnung, keine Neuanlage bei Treffer | KundenNrZahl, aus der Suche |
| billingAddress.countryIsoISO-2, Wert DE | läuftUmschlüsselung ISO-2 auf ISO-3 | LandKzText 3, Wert DEU |
| lineItem.unitPriceDezimal, brutto | prüfenUmrechnung auf netto, Rundung auf zwei Stellen einmal fachlich bestätigt | EPreisNettoDezimal 10,2 |
| customer.companyText, bis 255 | prüfenKürzung auf 40 Zeichen, voller Wert bleibt im Protokoll | Firma1Text, 40 Zeichen |
| customer.vatIdText, optional | KonfliktIm Ziel Pflichtfeld für Firmenkunden – ohne Wert entsteht kein Auftrag | USTIDNRText, Pflichtfeld |
| order.customerCommentText, bis 2000 | ausgeschlossenKein Zielfeld, bewusst nicht übertragen | ohne Zielbleibt im Shop |
Ergebnis für Bestellung 10842
- 3laufen durch
- 2einmal bestätigt
- 1Konflikt
- 1bewusst ohne Ziel
Sieben Felder, und eines entscheidet: Ohne Umsatzsteuer-ID entsteht in der Warenwirtschaft kein Auftrag. Bestellung 10842 steht um 09:14 Uhr mit Grund in der Fehlerliste – nicht halb angelegt im Zielsystem.
Wiederholungspfad bei Fehlern
- Versuch 1sofort
- Versuch 2nach 2 Minuten
- Versuch 3nach 15 Minuten
- Fehlerlistezuständige Person informiert
Wiederholt wird nur, was technisch scheitert: Zeitüberschreitung, Wartungsfenster, Sperre wegen zu vieler Aufrufe. Die fehlende Umsatzsteuer-ID weiter oben ist ein fachlicher Fehler – ein vierter Versuch findet sie auch nicht. Solche Datensätze gehen ohne Umweg in die Liste.
Entscheidend sind die letzten beiden Zeilen. Eine Integration ist fertig, wenn feststeht, was sie nicht überträgt – nicht, wenn der erste Datensatz ankommt.
Zeile 4 ist der typische Fall: Der Shop rechnet brutto, die Warenwirtschaft erwartet netto. Die Rückrechnung ist Mathematik, die Frage nach der Rundung eine fachliche Entscheidung. Sie wird einmal getroffen und steht danach in der Tabelle.
Von der Feldliste zur laufenden Strecke
-
Felder erheben, nicht Systeme
Wir gehen nicht von „Shop an ERP“ aus, sondern Feld für Feld: Welches Feld existiert auf beiden Seiten, wer darf es ändern, was gilt bei einem Leerwert. Das Ergebnis ist die Tabelle oben – sie ist die eigentliche Projektgrundlage.
-
Auslöser und Reihenfolge festlegen
Jede Strecke bekommt ein Ereignis: einen Webhook beim Speichern, einen Zeitplan oder einen Abgleich über Änderungsstempel. Dazu die Regel, was gilt, wenn derselbe Datensatz von beiden Seiten kommt.
-
Gegen echte Altdaten testen
Die Strecke läuft zuerst gegen eine Kopie oder einen Testmandanten, gefüttert mit Datensätzen aus der Vergangenheit. Dort tauchen die Sonderfälle auf, die im Gespräch niemand nennt – Umlaute, leere Pflichtfelder, doppelte Kunden.
-
Fehlerweg bauen, bevor es produktiv geht
Technische Fehler werden nach festem Muster wiederholt, fachliche gehen sofort in eine Liste mit Ursache, Nutzdaten und zuständiger Person. Nichts scheitert still, und nichts wird zweimal geschrieben.
-
Schrittweise scharf schalten
Erst eine Richtung, dann die zweite. Erst Neuanlagen, dann Änderungen. Der Altbestand wird einmalig und kontrolliert abgeglichen, nicht nebenbei im laufenden Betrieb.
Was sich im Alltag ändert
Heute
- Dieselbe Adresse wird in zwei Systeme getippt
- Nächtlicher Export, tagsüber veraltete Zahlen
- Niemand weiß, welches System bei Widerspruch recht hat
- Ein fehlgeschlagener Import fällt Wochen später auf
- Jede Feldänderung im ERP bricht den Export stillschweigend
Mit angebundenen Systemen
- Der Datensatz entsteht einmal und läuft von dort weiter
- Die Änderung steht Sekunden später im Zielsystem
- Je Feld ist festgelegt, welche Seite gewinnt
- Was nicht durchgeht, steht mit Ursache in einer Liste
- Ein Abbruch meldet sich, statt still liegen zu bleiben
Wo eine Integration nicht die Antwort ist
Datenabgleich sieht von außen nach einem reinen Technikthema aus. Diese vier Punkte klären wir vor dem Angebot, weil sie über den Nutzen entscheiden:
- Bei kleinen Mengen lohnt sich der Bau nicht. Wenn zwischen zwei Systemen am Tag zehn Datensätze wandern, sind die in wenigen Minuten getippt – und getippt werden sie ohne Wartung, ohne Zugangsdaten und ohne Abhängigkeit von einer fremden Schnittstelle. Wir sagen das im Erstgespräch, auch wenn es den Auftrag kostet. Interessant wird es dort, wo täglich viele Datensätze laufen oder wo ein Fehler teuer ist.
- Ohne Schnittstelle gibt es keinen Abgleich in Echtzeit. Ältere Branchensoftware bietet oft keine API. Dann bleiben ein Datenbankzugriff, ein Dateiexport oder – im schlechtesten Fall – ein nachgebauter Klickpfad in der Oberfläche. Die ersten beiden Wege sind stabil, der letzte bricht bei jedem Update des Herstellers. Wo nur der Klickpfad bleibt, raten wir ab.
- Die Datenqualität wird nicht besser, sondern sichtbar. Eine Synchronisation kopiert auch Dubletten, Zahlendreher und halb gepflegte Adressen – nur schneller und in beide Richtungen. Wer heute zwei widersprüchliche Stammdatenbestände hat, muss vorher entscheiden, welcher gilt. Diese Entscheidung nimmt Ihnen keine Software ab, und sie kostet Zeit im eigenen Haus.
- Fremde Systeme ändern sich ohne Sie. Ein Anbieter kann eine API-Version abkündigen, ein Feld umbenennen oder das Aufruflimit senken. Dann läuft die Strecke bis zum Stichtag und danach nicht mehr. Wir bauen Protokoll und Benachrichtigung ein, damit das sofort auffällt – die Anpassung selbst bleibt aber Arbeit. Rechnen Sie mit Wartung, nicht nur mit dem Bau.
Passt zu Ihren Systemen
Leistungsumfang und Preis
Der Einstiegspreis deckt eine Strecke zwischen zwei Systemen ab – in einer Richtung, nicht in beiden, samt Mapping, Fehlerweg und Protokoll. Was den Preis bewegt, sagen wir vor dem Angebot.
- Eine Strecke zwischen zwei Systemen, in einer Richtung produktiv
- Feld-Mapping als Tabelle: Quellfeld, Regel, Zielfeld, Datenhoheit
- Auslöser nach Wahl: Webhook, Zeitplan oder Änderungsstempel
- Umwandlungen für Formate, Schlüssel, Einheiten und Währungen
- Fehlerstrecke mit Wiederholung, Ursache und Nutzdaten
- Protokoll je Datensatz und Benachrichtigung bei Abbruch
- Dokumentation, Einweisung und 30 Tage Support
Was den Preis erhöht
- Abgleich in beide Richtungen mit Vorrangregel je Feld
- Mehr als zwei Systeme oder mehrere Datenobjekte je Strecke
- Systeme ohne API: Adapter über Datenbank, Datei oder SFTP
- Einmalige Übernahme des Altbestands samt Dublettenprüfung
- Hohe Mengen oder enge Aufruflimits, die eine Warteschlange nötig machen
Ein beidseitiger Abgleich mehrerer Datenobjekte über drei oder mehr Systeme liegt erfahrungsgemäß deutlich darüber, in der Größenordnung ab 3.900 €. Den verbindlichen Festpreis nennen wir nach dem Erstgespräch.
Alle Preise zzgl. MwSt. · Betrieb und Weiterentwicklung optional per Abo-Paket
Was Sie erhalten
-
Produktive Strecke
Von Auslöser bis Zielsystem eingerichtet und mit echten Datensätzen abgenommen
-
Mapping-Tabelle
Jedes Feld mit Regel, Datenhoheit und Verhalten bei Leerwerten – die Grundlage für jede spätere Änderung
-
Fehlerstrecke und Protokoll
Wiederholung bei technischen Fehlern, Liste mit Ursache und Nutzdaten bei fachlichen
-
Übergabe an Ihre IT
Zugänge, Betriebsanleitung und eine klare Antwort darauf, was zu tun ist, wenn ein Hersteller seine Schnittstelle ändert
Häufige Fragen zur API-Integration
Diese Lösungen passen dazu
Excel-Daten automatisch synchronisieren
Die kleine Schwester: gleiche Logik, wenn eine Seite eine Tabelle statt eines Systems ist.
Kundendaten-Änderungen automatisieren
Adressänderung an einer Stelle erfassen und in alle angebundenen Systeme durchreichen.
E-Commerce Automatisierung
Der häufigste Anwendungsfall im Detail: Bestellung, Bestand und Versand zwischen Shop und Lager.
Backups & System-Monitoring
Überwachung für alles, was danach laufen muss – inklusive Meldung, wenn eine Strecke stillsteht.
Welche Daten tippen Sie zweimal?
Im kostenlosen Erstgespräch nehmen wir eine einzige Strecke auseinander: welche Felder wirklich wandern müssen, wer sie ändern darf und was passieren soll, wenn ein System nicht antwortet. Danach wissen Sie, ob sich der Bau lohnt – oder ob zehn Datensätze am Tag schneller getippt sind.
Kostenloses ErstgesprächWo API-Integration und Datensynchronisation im Alltag wirklich wirkt
CRM, ERP, Shop und individuelle Systeme tauschen definierte Daten ereignisgesteuert aus, mit Validierung, Protokoll und kontrolliertem Wiederanlauf.
Drei typische Einsatzfelder – konkret genug, um den eigenen Prozess dagegen zu halten.CRM und ERP synchronisieren
Kunden, Aufträge und Status bleiben über definierte Feld- und Eigentumsregeln konsistent.
Shop und Warenwirtschaft verbinden
Bestellung, Bestand und Versandinformation fließen ereignisgesteuert zwischen den Systemen.
Fehler kontrolliert behandeln
Ungültige Datensätze landen mit Ursache, Payload und Wiederholungsoption in einer Fehlerstrecke.
Ein guter Fit, wenn …
Systeme liefern strukturierte Signale oder Daten und technische Ausnahmen sollen mit Protokoll, Kontext und klarer Zuständigkeit eskalieren.
- Sie bearbeiten regelmäßig datensätze nach wiederkehrenden Regeln.
- Eingang, Zielsystem und fachlich verantwortliche Rolle lassen sich eindeutig benennen.
- Ausnahmen dürfen sichtbar bleiben und gezielt an Menschen gehen.
Bewusste Grenze der Automation
Widersprüchliche Stammdaten, fehlende Pflichtfelder und fachlich unklare Zuordnungen werden nicht blind überschrieben.
Technischen Ansatz und Plattformen ansehenZeitgewinn mit eigenen Annahmen einschätzen
Der Rechner nutzt 4 Minuten heute und 0.5 Minuten nach Automatisierung als veränderungsfeste Beispielannahme. Er ersetzt keine Prozessanalyse.
Orientierungswert auf Basis der sichtbaren Annahmen – keine Garantie.