Die Integration fremder APIs ist die am zuverlässigsten unterschätzte Arbeit in kommerzieller Software. Die Dokumentation liest sich klar, der Anbieter veröffentlicht eine Client-Bibliothek, und jemand sagt zwei Wochen. Sechs Wochen später streitet das Team noch darüber, was passieren soll, wenn ein Webhook zweimal für eine Bestellung eintrifft, die bereits erstattet wurde.

Die Lücke ist keine Unfähigkeit. Sie entsteht, weil der interessante Teil einer Integration nie die Anfrage und die Antwort ist. Es ist alles, was passiert, wenn sich das andere System so verhält, wie es seine Dokumentation nie beschrieben hat, und das wird es, denn es ist ein lebendes Produkt von Menschen mit eigener Roadmap und ohne jede Verpflichtung gegenüber Ihrem Releaseplan.

Die Faustregel: Eine lesende Integration, die Daten aus einem Dienst zieht, dauert meist ein bis drei Wochen. Eine Integration, die Transaktionen schreibt, drei bis sechs. Eine beidseitige Synchronisation zwischen Systemen, die beide Änderungen erlauben, dauert sechs bis zwölf Wochen und wird nie wirklich fertig, weil Konfliktauflösung ein Geschäftsproblem im Ingenieurskostüm ist.

Warum Integrationsschätzungen immer falsch sind

Schätzungen stammen vom glücklichen Pfad, und der glückliche Pfad ist vielleicht ein Fünftel der Arbeit.

Den Code zu schreiben, der einen Kundendatensatz holt, auf Ihr Modell abbildet und speichert, dauert einen Nachmittag. Dann meldet sich die Wirklichkeit. Das Token läuft mitten im Stapel ab. Der Anbieter antwortet mit einer Ratenbegrenzung, ohne je erwähnt zu haben, dass das Limit täglich statt pro Minute gilt. Ein Feld, das die Dokumentation als Ganzzahl beschreibt, kommt bei einem Altbestandskonto als Zeichenkette an. Die Paginierung liefert einen Datensatz doppelt, weil ihn jemand während des Lesens bearbeitet hat. Die Testumgebung akzeptiert eine Nutzlast, die die Produktion ablehnt, weil sie zuletzt 2023 aktualisiert wurde.

Nichts davon ist exotisch. Das ist das gewöhnliche Wetter der Integrationsarbeit, und jeder dieser Punkte wird zu einer Entwurfsentscheidung, die jemand treffen und testen muss. Teams, die das schon kennen, bauen von Anfang an dafür. Teams, die es nicht kennen, entdecken sie einzeln, in der Produktion, meist an einem Freitag.

Die vier Arten von Integration und warum sie unterschiedlich kosten

Bevor Sie irgendetwas schätzen, klären Sie, welche davon Sie tatsächlich bauen. Zwischen der ersten und der letzten liegt ungefähr eine Zehnerpotenz.

Lesender Abruf. Sie holen regelmäßig Daten aus einem anderen System und speichern oder zeigen sie an. Fehler lassen sich durch erneutes Versuchen beheben, und nichts nachgelagert wird beschädigt, wenn ein Lauf ausfällt. Das ist mit Abstand die günstigste und berechenbarste Kategorie.

Transaktionales Schreiben. Sie senden etwas, das anderswo den Zustand ändert: eine Zahlung, eine Bestellung, eine Sendungsbuchung, ein Support-Ticket. Jetzt zählt Korrektheit, denn eine doppelte oder verlorene Anfrage hat finanzielle oder vertragliche Folgen. Idempotenz, Abgleich und klare Fehlerbehandlung werden Pflicht statt Kür.

Ereignisgetriebener Empfang. Das andere System benachrichtigt Sie, wenn etwas geschieht, meist über Webhooks. Das ist effizient und beseitigt Abfrageverzögerungen, bringt aber eine ganze Klasse von Problemen rund um Zustellgarantien, Reihenfolge und Prüfung mit sich, die es beim Abfragen nie gab.

Beidseitige Synchronisation. Beide Systeme halten dieselben Daten und beide erlauben deren Bearbeitung. Das ist die teure Variante, und die Kosten sind nicht technisch. Jemand im Geschäft muss entscheiden, was passiert, wenn ein Datensatz binnen derselben Minute an beiden Stellen bearbeitet wird, und dieses Gespräch dauert meist länger als die Umsetzung.

Wo Integrationen tatsächlich brechen

Die Fehlerbilder wiederholen sich über jeden Anbieter und jede Branche hinweg. Wenn Ihr Entwicklungspartner darüber nicht flüssig sprechen kann, hat er nicht viele Integrationen gebaut.

Ablauf der Authentifizierung. OAuth-Refresh-Token rotieren, werden bei Passwortänderungen widerrufen und hören still auf zu funktionieren, wenn ein Administrator eine Berechtigung entfernt. Eine Integration, die Zugangsdaten für dauerhaft hält, läuft vier Monate wunderbar und fällt dann über Nacht aus, ohne dass eine Codeänderung schuld wäre. Bewahren Sie Token zentral auf, erneuern Sie sie vorausschauend statt reaktiv, und alarmieren Sie bei Authentifizierungsfehlern als eigener Kategorie.

Ratenbegrenzungen. Limits sind häufig undokumentiert, gelten je Endpunkt statt global und sind in der Produktion strenger als in der Testumgebung. Beachten Sie die Wiederholungs-Header, wenn es sie gibt, warten Sie exponentiell mit Streuung, wenn nicht, und lassen Sie nie einen Stapeljob mit voller Geschwindigkeit auf einen Endpunkt eindreschen, nur weil es beim Testen klappte.

Paginierung, die sich unter Ihnen verschiebt. Offset-basierte Paginierung über einen Datenbestand, den andere bearbeiten, wird Datensätze doppeln und überspringen. Cursor-basierte meist nicht. Bietet der Anbieter beides, nehmen Sie Cursor; bietet er es nicht, ergänzen Sie einen Abgleich, damit Sie die Lücken bemerken.

Teilweises Scheitern. Eine Anfrage mit Zeitüberschreitung hat einen unbekannten Ausgang: sie kann erfolgreich, gescheitert oder langsam erfolgreich gewesen sein. Blindes Wiederholen erzeugt Duplikate, Nichtwiederholen verliert Transaktionen. Die Antwort ist ein von Ihnen erzeugter Idempotenzschlüssel bei jedem Schreibvorgang, damit der Anbieter eine Wiederholung erkennt, plus ein Abgleichprozess, der beide Systeme planmäßig vergleicht.

Die Fehler, die erst in der Produktion auftauchen

Webhooks, die lügen. Webhook-Zustellung ist mindestens einmal, nicht genau einmal, und die Reihenfolge ist nicht garantiert. Sie werden Duplikate erhalten, Ereignisse außer der Reihe bekommen und gelegentlich ein Ereignis für einen Datensatz, dessen Erstellungsereignis noch nicht eingetroffen ist. Prüfen Sie Signaturen bei jeder Nutzlast, antworten Sie sofort und verarbeiten Sie asynchron über eine Warteschlange, entdoppeln Sie über die Ereigniskennung, und entwerfen Sie Handler so, dass dasselbe Ereignis zweimal angewendet keinen Schaden anrichtet.

Schema-Drift. Anbieter ergänzen Felder, erweitern Aufzählungen und ändern gelegentlich Verhalten ohne Versionssprung. Strenge Parser brechen bei unbekannten Werten; nachsichtige Parser ignorieren still Daten, auf die es ankam. Validieren Sie, worauf Sie sich verlassen, tolerieren Sie den Rest, und protokollieren Sie unbekannte Werte, damit jemand es erfährt, bevor ein Kunde es tut.

Abweichende Testumgebung. Testumgebungen sind meist vereinfacht, oft veraltet und verhalten sich manchmal genau dort anders, wo es zählt: Zeitverhalten, Strenge der Validierung, Fehlercodes. Planen Sie einen kontrollierten Produktionsversuch mit echten Zugangsdaten und kleinen Mengen ein, denn dort wohnt die letzte Überraschung.

Beidseitige Synchronisation verdient eine eigene Warnung

Zweiwege-Synchronisation sieht nach doppelter Arbeit gegenüber einer Richtung aus und liegt eher beim Fünffachen, weil sie Fragen aufwirft, die keine technisch richtige Antwort haben.

Angenommen, die Adresse eines Kunden wird binnen einer Stunde in Ihrer Anwendung und im CRM Ihres Kunden geändert. Welche gewinnt? Letzter Schreibvorgang gewinnt ist leicht umzusetzen und zerstört still Daten, besonders wenn Uhrenversatz zwischen Systemen “letzter” mehrdeutig macht. Feldweises Zusammenführen bewahrt mehr, verlangt aber Änderungsverfolgung auf beiden Seiten, die die meisten Anbieter-APIs nicht offenlegen. Manuelle Konfliktauflösung ist ehrlich, braucht aber eine Oberfläche, eine Warteschlange und jemanden, der bereit ist hineinzuschauen.

Löschungen sind schlimmer. Ein in einem System gelöschter Datensatz muss im anderen vielleicht archiviert, anonymisiert oder nur markiert werden, und wenn Sie es in der Richtung falsch machen, die sich fortpflanzt, ist der Fehler nicht behebbar. Die meisten erfahrenen Teams weigern sich, Löschungen überhaupt automatisch zu synchronisieren, und das ist meist richtig.

Der praktische Rat lautet, echte beidseitige Synchronisation zu vermeiden, sofern das Geschäft sie nicht wirklich verlangt. Ein System je Feld als maßgeblich zu bestimmen und Änderungen nur in eine Richtung zu schieben, beseitigt fast die gesamte Schwierigkeit. Wenn Sie zwischen dem Bau eines Konnektors und einer Plattform mit vorhandenem Konnektor wählen, behandelt unser Leitfaden zu Eigenbau oder Zukauf die kaufmännische Seite dieser Abwägung.

Was die Integration fremder APIs kostet

Die Zahlen unten setzen britische Agentursätze voraus sowie eine Anwendung, die bereits ein Backend, Hintergrundverarbeitung und irgendeine Form von Monitoring hat. Rechnen Sie Zeit hinzu, wenn etwas davon fehlt.

Eine unkomplizierte lesende Integration mit einer gut dokumentierten API läuft typischerweise von 4.000 bis 12.000 Pfund und deckt Client, Fehlerbehandlung, Zeitsteuerung, Abbildung und Tests ab. Transaktionale Integrationen, die Geld bewegen oder Verpflichtungen erzeugen, landen meist zwischen 12.000 und 30.000 Pfund, weil Idempotenz, Abgleich und Prüfprotokoll allesamt Pflicht sind. Beidseitige Synchronisation zwischen zwei führenden Systemen beginnt bei rund 30.000 Pfund und steigt rasch mit der Zahl der Entitäten und der Komplexität der Konfliktregeln.

Dann gibt es den Teil, den niemand anbietet. Jede laufende Integration braucht Wartung, weil sich die andere Seite weiter verändert. Planen Sie jährlich zehn bis zwanzig Prozent der ursprünglichen Baukosten für Versionswechsel, Abkündigungen, Rotation von Zugangsdaten und den gelegentlichen Notfall ein, wenn ein Anbieter eine brechende Änderung ohne ausreichende Vorwarnung ausliefert. Eine Organisation mit fünfzehn Integrationen hat eine laufende Wartungsverpflichtung, ob sie damit geplant hat oder nicht.

Für das größere Bild, wie sich Integrationsarbeit in ein Lieferbudget einfügt, legt unser Leitfaden zu Kosten individueller Softwareentwicklung die umliegenden Posten dar.

Wie eine gut gebaute Integration aussieht

Eine solide Integration erkennen Sie daran, was sie tut, wenn etwas schiefgeht, also sind das die Details, auf denen zu bestehen sich lohnt.

Jeder ausgehende Schreibvorgang trägt einen Idempotenzschlüssel, damit eine Wiederholung keine Transaktion doppeln kann. Jeder eingehende Webhook wird signaturgeprüft, sofort bestätigt und aus einer Warteschlange verarbeitet, damit ein langsamer Handler den Anbieter nie zu Wiederholungen zwingt. Fehlgeschlagene Nachrichten landen in einer Warteschlange für unzustellbare Nachrichten, wo man sie prüfen und erneut einspielen kann, statt dass sie in einer Logdatei verschwinden.

Anfragen und Antworten werden mit Korrelationskennungen protokolliert, damit eine Supportfrage zu einer Bestellung in Minuten statt durch Raten beantwortet wird. Zugangsdaten liegen in einem Geheimnisspeicher mit dokumentiertem Rotationsprozess, nicht in Umgebungsvariablen, an deren Setzen sich niemand erinnert. Ein Schutzschalter stoppt Aufrufe an einen ausfallenden Anbieter nach einer Schwelle und schützt so Ihren wie dessen Dienst vor einem Wiederholungssturm.

Zuletzt gibt es einen Abgleichlauf. Er vergleicht Ihre Datensätze planmäßig mit deren und meldet Unterschiede. Er ist unglamourös, er ist das Erste, was bei knappem Termin gestrichen wird, und er ist der einzige Grund, warum irgendwer je die einunddreißig Bestellungen findet, die letzten Monat still gescheitert sind.

Bauen Sie Integrationen, die den Anbieter überleben

Mecanik baut und pflegt Integrationen fremder APIs im Rahmen unserer individuellen Softwareentwicklung , von Zahlungsanbietern über Logistikdienstleister und CRM- und ERP-Plattformen bis zu den sperrigen internen Systemen, die nur einen SOAP-Endpunkt und eine Telefonnummer für den Support haben.

Wir bauen Warteschlange, Idempotenzschicht, Abgleich und Alarmierung standardmäßig, weil genau diese Bestandteile entscheiden, ob eine Integration ein Vermögenswert oder ein wiederkehrender Vorfall ist. Wenn Ihre Integration eher ein Sprachmodell als eine klassische API betrifft, erklärt unser Leitfaden zur OpenAI-API-Integration die Unterschiede. Wird die API-Schicht selbst auf moderner Infrastruktur benötigt, zeigt unsere Anleitung zu serverlosen APIs mit Cloudflare Workers den von uns bevorzugten Ansatz.

Schicken Sie uns die Dokumentation des Anbieters und eine Beschreibung dessen, was passieren soll, und Sie erhalten eine abgegrenzte Schätzung, in der die Fehlerbehandlung enthalten ist statt später angeschraubt.

Siehe auch: CRM- und ERP-Integration: Kosten, Wege, Fallstricke , API-Entwicklung Kosten: Wofür Sie 2026 zahlen , Software-Lizenzmodelle: Leitfaden für Unternehmen 2026 , REST API vs GraphQL in 2026 .

Häufig gestellte Fragen

Wie lange dauert die Integration einer fremden API? Eine lesende Integration dauert meist ein bis drei Wochen, eine transaktionale drei bis sechs, und eine beidseitige Synchronisation sechs bis zwölf Wochen. Der Unterschied liegt nicht im Aufruf selbst, sondern in Idempotenz, Abgleich und der Frage, wer bei widersprüchlichen Änderungen gewinnt.

Warum liegen Schätzungen für API-Integrationen so oft daneben? Weil sie vom glücklichen Pfad stammen, der etwa ein Fünftel der Arbeit ausmacht. Ablaufende Token, undokumentierte Ratenbegrenzungen, Felder mit falschem Typ bei Altkonten, verschobene Paginierung und veraltete Testumgebungen sind das gewöhnliche Wetter dieser Arbeit und werden jeweils zu einer Entwurfsentscheidung.

Wie geht man mit Webhooks um, die doppelt ankommen? Webhook-Zustellung ist mindestens einmal und ohne Reihenfolgegarantie. Prüfen Sie die Signatur jeder Nutzlast, antworten Sie sofort und verarbeiten Sie asynchron über eine Warteschlange, entdoppeln Sie über die Ereigniskennung und entwerfen Sie Handler so, dass die zweifache Anwendung desselben Ereignisses folgenlos bleibt.

Was kostet eine Integration mit einer fremden API? Eine lesende Integration liegt typischerweise zwischen 4.000 und 12.000 Pfund, eine transaktionale zwischen 12.000 und 30.000, und beidseitige Synchronisation beginnt bei rund 30.000. Planen Sie zusätzlich jährlich zehn bis zwanzig Prozent der Baukosten für Wartung ein, weil die andere Seite sich weiter ändert.

Sollte ich eine beidseitige Synchronisation bauen? Nur wenn das Geschäft sie wirklich verlangt. Sie kostet eher das Fünffache einer Richtung, weil Konfliktauflösung und Löschverhalten Geschäftsfragen ohne technisch richtige Antwort sind. Bestimmen Sie je Feld ein maßgebliches System und schieben Sie Änderungen nur in eine Richtung.