Webhook, API oder RPA: wie du Systeme richtig verbindest
Kurzantwort
Zwei Systeme verbindet man auf drei Arten: ein Webhook schickt eine Nachricht, sobald etwas passiert, eine API liest und schreibt Daten strukturiert auf Abruf, und RPA klickt die Oberfläche, wenn es keine Schnittstelle gibt. RPA ist die letzte Wahl, sobald ein echtes Interface existiert.
Kurz zusammengefasst
Wenn zwei Tools miteinander reden sollen, ist die erste Frage nicht welches Automatisierungstool, sondern über welchen Weg. Es gibt drei: Webhook (Push bei einem Ereignis), API (strukturiertes Lesen und Schreiben auf Abruf) und RPA (die Oberfläche fernsteuern, wenn es keine Schnittstelle gibt). Webhook und API sind für Maschinen gebaut und im Betrieb stabil. RPA ist ein Notausgang, kein Standardweg. Die wichtigste Weiche neben der Wahl des Wegs ist der Fehlerfall: Eine Verbindung ist erst dann robust, wenn geplant ist, was bei einem Timeout, einem Rate-Limit oder einer verpassten Zustellung passiert.
Drei Wege, ein Ziel
Bei jeder Automatisierung kommt der Moment, in dem zwei Systeme miteinander reden müssen: das Formular und das CRM, der Shop und die Buchhaltung, das Ticketsystem und der Chat. Für diese Verbindung gibt es keine magische Lösung, sondern drei nüchterne Wege. Wer sie auseinanderhält, trifft die Wahl in Minuten statt in Meetings.
Ein Webhook ist ein Anruf, den ein System von sich aus tätigt, sobald etwas passiert. Neue Bestellung, neues Formular, neue Zahlung, und im selben Moment schickt die Quelle eine kleine Nachricht an eine feste Adresse. Du fragst nicht nach, du wirst benachrichtigt. Das ist schnell und sparsam, weil nichts im Leerlauf pollt.
Eine API ist die Tür, durch die du gezielt hineingehst. Du rufst eine dokumentierte Schnittstelle auf, um genau die Datensätze zu lesen oder zu schreiben, die du brauchst, wann du sie brauchst. APIs sind für Maschinen gebaut: mit Authentifizierung, klaren Fehlercodes und einer Version, auf die man sich verlassen kann. Deshalb sind sie der belastbarste Weg, wenn du Kontrolle über Timing und Datenformat brauchst.
RPA steht für Robotic Process Automation und ist der dritte Weg: Ein Roboter bedient die Oberfläche wie ein Mensch, klickt Felder an, tippt ein, liest ab. Man nimmt ihn, wenn ein System weder Webhook noch API anbietet und die einzige Tür der Bildschirm ist. RPA löst genau dieses Problem und schafft dabei ein neues, auf das ich gleich komme.
Wann welcher Weg passt
Die Wahl hängt an drei Fragen: Meldet sich die Quelle von selbst, brauchst du gezielten Zugriff auf einzelne Datensätze, und gibt es überhaupt eine Schnittstelle. Aus den Antworten fällt der Weg fast von allein heraus.
| Methode | Wann sinnvoll | Risiko |
|---|---|---|
| Webhook | Quelle meldet Ereignisse aktiv, du willst sofort reagieren | verpasste Zustellung, wenn der Empfänger down ist und niemand wiederholt |
| API | du liest oder schreibst gezielt Datensätze und brauchst Kontrolle über Timing | Rate-Limits, Auth-Aufwand, Wechsel der Version |
| RPA | kein Webhook und keine API vorhanden, nur eine Oberfläche | bricht bei jedem UI-Update, langsam, schwer zu skalieren |
| Manueller Export/Import | einmalig oder sehr selten, kein Budget für eine Anbindung | menschliche Fehler, keine Aktualität, nicht wiederholbar |
In der Praxis kombiniert man oft zwei Wege: Ein Webhook meldet, dass etwas passiert ist, und ein API-Aufruf holt danach die vollständigen Daten. Der Webhook ist der Türklopfer, die API der Blick in den Raum. Diese Kombination ist bei sauberer Systeme-verbinden-Automatisierung eher die Regel als die Ausnahme.
RPA ist die letzte Wahl
RPA ist verführerisch, weil es fast immer geht. Es gibt kein System, das man nicht irgendwie fernsteuern könnte, solange ein Bildschirm da ist. Genau das macht es gefährlich. Ein Klick-Roboter hängt an der Position von Buttons, an Feldbeschriftungen, an Ladezeiten. Verschiebt ein Update die Oberfläche um zwei Pixel oder benennt ein Feld um, steht der ganze Ablauf still, und niemand bemerkt es, bis die Zahlen nicht mehr stimmen.
RPA ist ein Notausgang. Er ist großartig, wenn es keine andere Tür gibt, und ein Risiko in dem Moment, in dem es eine gibt.
Die Regel ist einfach: Wenn ein System eine API oder einen Webhook anbietet, nimm die. Sie sind für genau diesen Zweck gebaut, sie überstehen Updates, und sie sagen dir, wenn etwas schiefgeht. RPA gehört an die Stellen, wo eine Anbindung schlicht nicht existiert, etwa bei einer alten Fachanwendung ohne Schnittstelle. Und selbst dort behandelt man es als Übergang, nicht als Dauerlösung, und prüft regelmäßig, ob inzwischen eine echte Schnittstelle bereitsteht.
Den Fehlerfall mitbauen
Die meisten Verbindungen funktionieren am ersten Tag. Sie scheitern an Tag vierzig, wenn die Quelle kurz nicht erreichbar ist, ein Limit greift oder ein Datensatz anders aussieht als erwartet. Eine robuste Anbindung unterscheidet sich von einer fragilen nicht am Normalfall, sondern daran, was im Ausnahmefall passiert.
Drei Dinge braucht jede ernsthafte Verbindung. Sie muss Fehler erkennen, statt sie stumm zu schlucken. Sie muss es sinnvoll erneut versuchen, mit Abstand zwischen den Versuchen, damit ein kurzer Ausfall nicht zum Datenverlust wird. Und sie muss einen Weg haben, den Menschen zu rufen, wenn ein Fall wirklich nicht automatisch lösbar ist. Wer diese drei Punkte vor dem Bau klärt, baut eine Verbindung, die auch im zweiten Monat noch trägt.
Die Vorab-Checkliste
Bevor du zwei Systeme verbindest, beantworte diese fünf Fragen. Bleibst du bei einer hängen, hast du die schwache Stelle der Anbindung gefunden, bevor sie im Betrieb auffällt.
- Bietet die Quelle einen Webhook, oder musst du aktiv abfragen?
- Gibt es eine dokumentierte API, und mit welchen Limits und welcher Version?
- Ist RPA wirklich nötig, oder gibt es doch eine Schnittstelle, die niemand gesucht hat?
- Was passiert bei einem Fehler, und nach wie vielen Versuchen übernimmt ein Mensch?
- Wer merkt es, wenn die Verbindung still stehen bleibt?
Kernsatz: Eine Verbindung ist so gut wie ihr Verhalten im Ausnahmefall. Der Normalfall verrät dir wenig, der Fehlerfall alles.
Häufige Irrtümer
- RPA und API sind austauschbare Wege zum selben Ziel.
- Sie lösen dasselbe Problem, aber auf sehr unterschiedlichem Fundament. Eine API ist eine vereinbarte Schnittstelle, RPA ist eine Nachahmung menschlicher Klicks. Sobald es eine API gibt, ist RPA der schlechtere Weg.
- Ein Webhook garantiert, dass die Nachricht ankommt.
- Nur, wenn Empfänger und Sender das absichern. Ohne Quittung und Wiederholung kann eine Zustellung leise verloren gehen. Für kritische Ereignisse gehört ein Abgleich dazu.
Fragen und Antworten
- Kann ich einfach immer die API nehmen, um sicherzugehen?
- Wenn es eine gibt und du gezielten Zugriff brauchst, ist sie meist die beste Wahl. Willst du aber nur auf Ereignisse reagieren, ist ein Webhook sparsamer, weil du nicht permanent nachfragen musst. Oft ist die Kombination aus beidem am stärksten.
- Woran erkenne ich, dass RPA mich später einholt?
- An jeder Meldung, die mit einem geänderten Feld, einem verschobenen Button oder einer neuen Login-Maske zu tun hat. Häufen sich solche Ausfälle, ist das der Hinweis, dass eine echte Schnittstelle die günstigere Lösung wäre.
- Wie viel Fehlerbehandlung ist genug?
- So viel, dass ein kurzer Ausfall der Gegenseite nicht zu Datenverlust führt und ein echter Sonderfall einen Menschen erreicht. Mehr Logik lohnt sich erst, wenn die Fälle es rechtfertigen.
Sources and evidence
Es werden keine externen Benchmarks oder Kundenergebnisse als belegt behauptet. Konkrete Limits, Versionen und Rechte werden vor dem Bau am realen System geprüft.