Zwei APIs zu verbinden, solange alles glatt läuft, ist der einfache Teil. Belastbar wird eine Integration durch Idempotenz, Retries, Fehlerbehandlung und Monitoring. Wir zeigen, worauf es beim Bau ankommt, und wie unser Vorgehen von der ersten Anbindung bis zum Betrieb aussieht.
Der Happy Path ist nicht die Arbeit
Zwei Systeme zu verbinden, solange beide erreichbar sind und die Daten sauber ankommen, kann fast jeder. Das ist der Happy Path, und er ist der einfache Teil. Die eigentliche Arbeit steckt in dem, was passiert, wenn es nicht glatt läuft: die API antwortet nicht, ein Webhook kommt doppelt, ein Aufruf schlägt zur Hälfte fehl, ein Limit greift.
Genau an diesen Stellen entscheidet sich, ob eine Integration im Betrieb trägt oder bei der ersten Störung stehen bleibt und jemand von Hand nacharbeiten muss. Deshalb bauen wir diese Fälle von Anfang an ein, statt sie später zu flicken.
Idempotenz: warum dieselbe Nachricht zweimal ankommen darf
Webhooks werden von den meisten Anbietern wiederholt, wenn die erste Zustellung nicht sauber quittiert wird. Das heißt, dasselbe Ereignis kann zwei- oder dreimal bei dir ankommen. Ohne Vorkehrung wird daraus ein doppelter Auftrag, ein doppelter Lead, eine doppelte Mail.
Die Lösung heißt Idempotenz: Jedes Ereignis bekommt eine eindeutige Kennung, die vor der Verarbeitung geprüft wird. Ist die Kennung schon bekannt, wird das Ereignis verworfen statt ein zweites Mal ausgeführt. Klingt banal, ist aber der Unterschied zwischen einer Pipeline, der du vertraust, und einer, die still Dubletten produziert.
Retries, Backoff und Rate-Limits
APIs fallen kurz aus, das ist normal. Ein belastbarer Bau gibt bei einem Fehler nicht sofort auf, sondern wiederholt den Aufruf mit wachsendem Abstand. Das nennt sich Backoff und verhindert, dass eine kurze Störung Daten kostet.
Dazu kommt der Umgang mit Rate-Limits. Viele APIs antworten unter Last mit einem 429 und einem Hinweis, wie lange man warten soll. Wer das ignoriert und stumpf weiterfeuert, wird ausgesperrt. Wir respektieren das Limit, legen Aufrufe in eine Warteschlange und arbeiten sie geordnet ab, statt die Gegenseite zu überrennen.
Fehler sichtbar machen: Logging und Monitoring
Der schlimmste Fehler ist der, den niemand sieht. Eine Integration, die still einen Datensatz verliert, ist gefährlicher als eine, die laut abbricht, weil der stille Verlust erst Wochen später auffällt, wenn die Zahlen nicht mehr stimmen.
Deshalb gehört Sichtbarkeit zum Bau: strukturierte Logs, eine Meldung, wenn ein Job fehlschlägt, und ein Weg, auf dem hängengebliebene Ereignisse landen, statt verloren zu gehen. Das Ziel ist einfach: Du sollst von einer Störung wissen, bevor dein Kunde sie merkt.
Der Bauplan: von der Anbindung bis 2 bis 4 Wochen live
Der Ablauf ist immer derselbe, unabhängig von den Tools:
- Kurzer Blick auf deine Systeme, Datenstruktur und die echten Sonderfälle.
- Bau der Module mit Idempotenz, Retries und Monitoring von Anfang an.
- Eine Kontrollschicht in der Mitte (zum Beispiel eine Tabelle oder eine kleine Datenbank), in der du siehst, was durchläuft, und die sich ohne Entwickler anfassen lässt.
- Test mit echten Randfällen, nicht nur mit dem Happy Path.
- Übergabe. Der Code gehört dir.
Ein klar umrissenes Modul geht so in der Regel in 2 bis 4 Wochen live. Der Stack ist bewusst gängig, je nach Fall n8n, Python-Cron, Supabase oder eigene Dienste auf Cloudflare und Azure, nichts Exotisches, das später niemand mehr warten kann.
Was das für dich heißt
Wenn du einen Partner für eine Integration bewertest, stell drei Fragen: Wie geht ihr mit doppelten Webhooks um, was passiert bei einem Ausfall der Gegenseite, und wie merke ich, wenn etwas hakt. Kommt darauf eine vage Antwort, wird die Integration im Betrieb Probleme machen.
Wenn du das in deinem Betrieb sauber aufsetzen willst, schreib uns kurz, welche Systeme du nutzt. Wir schauen es uns an und sagen dir konkret, wie der Bau aussieht. Festpreis pro Modul, du weißt vorher, was es kostet, und der Code gehört nach der Übergabe dir. Termin über Kontakt.