Was eine API-Integration wirklich löst
Du hast ein System, das Kundendaten verwaltet. Ein zweites, das Rechnungen erstellt. Ein drittes, das Bestände führt. Jedes davon ist in seinem Bereich gut. Das Problem entsteht an den Übergängen: sobald eine Information aus System A in System B gelangen muss, wird es umständlich. Im schlechtesten Fall tippt jemand die Daten zweimal ein. Im besten Fall exportiert ein Mitarbeiter eine CSV-Datei, schiebt sie in einen anderen Ordner und drückt einen Import-Knopf.
Beides kostet Zeit, und beides produziert Fehler. Eine API-Integration löst das, indem die Systeme direkt miteinander reden. Kein manueller Eingriff mehr. Die Daten wandern in Echtzeit oder in einem geplanten Intervall, und zwar genau dort hin, wo sie gebraucht werden.
Wie ich Integrationen baue
Bevor ich eine einzige Zeile Code schreibe, schaue ich mir die beiden Systeme an. Welche API haben sie überhaupt? REST, SOAP, proprietärer Endpoint, Datenbank-Zugriff? Wie authentifiziere ich mich? Wie ist das Datenmodell auf beiden Seiten? Wo sind die Felder, die abgeglichen werden müssen, und wo die, die nur in einem der beiden Systeme existieren?
Das klingt pedantisch, ist aber der wichtigste Schritt. Die meisten Integrationsprojekte gehen nicht an der Technik kaputt, sondern daran, dass die fachliche Zuordnung unklar war. Ein Beispiel: Dein ERP kennt einen Kunden nur mit einer einzigen Lieferadresse. Dein Shop erlaubt beliebig viele. Was passiert, wenn der Kunde im Shop eine neue Lieferadresse eingibt? Überschreiben? Ignorieren? Neuen Kunden anlegen? Das sind Entscheidungen, die nicht der Entwickler treffen soll, sondern du, und ich stelle die Fragen so, dass die Antworten ins Konzept passen.
Protokolle, mit denen ich arbeite
Die meisten modernen Systeme sprechen REST mit JSON. Das ist der einfachste Fall: saubere Endpoints, vernünftige Fehlercodes, gute Dokumentation. Aber die Realität in Schweizer KMU ist oft bunter.
- SOAP lebt noch in vielen älteren ERP-Systemen und Behörden-Schnittstellen. Unhandlich, aber funktioniert.
- EDI triffst du im Grosshandel und bei Marktplätzen. Edifact, X12, Tradacoms. Jedes Format hat seine Eigenheiten.
- XML-Dateiabgleich ist der Klassiker bei Abacus und SelectLine. Nicht sexy, aber stabil.
- Webhooks sind perfekt, wenn dein Quellsystem dich proaktiv informiert, sobald etwas passiert ist. Spart Polling und hält die Last niedrig.
- GraphQL sehe ich zunehmend bei neueren SaaS-Produkten. Eleganter als REST, wenn man selektiv Felder abfragen will.
Ich wähle nicht nach Coolness, sondern nach dem, was das Quellsystem anbietet und was zur Anforderung passt. Wenn EDI das richtige Werkzeug ist, nehme ich EDI.
Was dabei herauskommt
Eine saubere Integration sieht so aus: es gibt einen Service, der zwischen den beiden Systemen sitzt. Der Service kennt die Spielregeln beider Seiten, übersetzt die Datenformate, behandelt Fehler kontrolliert und protokolliert, was er tut. Du bekommst:
- Den Quellcode. Kein Black-Box-Service, den niemand ausser mir versteht. Saubere, kommentierte Implementierung, die ein anderer Entwickler übernehmen kann.
- Einen Monitoring-Zugang. Du siehst jederzeit, ob die Brücke läuft, wie viele Datensätze pro Tag übertragen werden und wo Fehler aufgetreten sind.
- Dokumentation. Nicht 200 Seiten Roman, sondern eine klare Beschreibung: was macht der Service, wie rufst du ihn an, was bedeuten die Logfiles.
- Einen sauberen Zugriff. Zugangsdaten sind in einem Secrets-Store, nicht im Code. Das System läuft mit einem dedizierten Nutzer, nicht mit deinem Admin-Account.
- Fehlerbehandlung, die Sinn ergibt. Wenn das Zielsystem mal nicht erreichbar ist, steht der Service nicht einfach, sondern behandelt es: Retry mit Backoff, Fehlermeldung an dich, kein stiller Datenverlust.
Was eine Integration nicht leistet
Eine API-Integration ist keine Wunderwaffe. Wenn deine Stammdaten auf beiden Seiten unsauber sind, dann synchronisiert die Integration halt zuverlässig Unsinn. Wenn dein Prozess an sich nicht durchdacht ist, dann automatisiert die Integration den undurchdachten Prozess. Und wenn zwei Systeme fachlich widersprüchliche Datenmodelle haben, dann muss jemand eine Entscheidung treffen, was Vorrang hat, das ist keine technische Frage.
Ich sage dir das vorher, nicht hinterher. In meinem Erstgespräch rede ich genau so lange über deinen Prozess wie über die Technik.
Ein konkreter Blick: Abacus-Shop-Integration
Ein häufiger Fall: Kunde hat Abacus als ERP und Shopify als Shop. Bestellungen sollen automatisch in Abacus landen, Lagerbestände sollen aus Abacus in den Shop, Artikelstammdaten werden in Abacus gepflegt und sollen in den Shop übernommen werden.
Das klingt wie ein Standardprozess, ist aber in jedem Betrieb anders. Fragen, die ich stelle: wie sieht dein Versandprozess aus? Fakturierst du aus Abacus oder aus Shopify? Was passiert mit Retouren? Wie handhabst du Teillieferungen? Rabatte? Promo-Codes, die nur im Shop existieren? Kundengruppen mit eigenen Preisen?
Erst wenn diese Fragen beantwortet sind, steht fest, welche Endpoints gebraucht werden, wie oft synchronisiert werden muss und was im Fehlerfall passiert. Das konkrete Coding ist dann oft der kleinere Teil des Aufwands.
Wann du mich kontaktieren solltest
- Du hast zwei oder mehr Systeme, zwischen denen Daten manuell hin und her wandern
- Ein Softwarehersteller hat dir einen Connector angeboten, der unverschämt teuer ist oder den du nicht brauchst
- Du willst einen neuen Shop, eine neue App oder eine neue Fachanwendung anbinden, aber dein IT-Partner kann oder will es nicht umsetzen
- Eine bestehende Schnittstelle ist instabil, und niemand versteht, warum
- Du planst eine grössere Prozessumstellung und willst vorher wissen, ob und wie die Systeme zusammenspielen können