Bitrix24 mit n8n verbinden: Webhooks, HTTP-Node und was im Portal bleibt

Zu n8n greift man, wenn das CRM mit etwas sprechen soll, das es nicht kennt: einer Lagerdatenbank, einem internen Dienst, einer fremden API. Die erste Stunde geht dann für eine Frage drauf, die Anleitungen auslassen — einen fertigen Node „Bitrix24“ gibt es auf der Arbeitsfläche nicht. Die Verbindung entsteht trotzdem sauber, nur eben aus allgemeinen Bausteinen, und sie bricht später immer an denselben Stellen. Hier die tragfähige Form einer Verbindung zwischen Bitrix24 (Alaio) und n8n, in beide Richtungen.

Gibt es einen Bitrix24-Node in n8n?

Keinen offiziellen. Die Bitrix24-Seite von n8n verweist auf den HTTP-Request-Node mit generischer Authentifizierung — die ehrliche Antwort: Sie rufen die REST-API selbst auf. Es gibt Pakete aus der Community, manche decken CRM-Entitäten, Aufgaben und Telefonie ordentlich ab, aber sie werden von Dritten gepflegt, hinken API-Änderungen hinterher, und auf verwalteten Instanzen ist ihre Installation eine Richtlinienfrage statt eines Klicks. Für ein Szenario mit drei bis vier Methoden ist der HTTP-Request-Node weniger Arbeit als das Prüfen fremden Codes: Die API ist schlichtes JSON über HTTPS, und ein Node bedient jede Methode.

Wie schreibt n8n Daten nach Bitrix24?

Über einen eingehenden Webhook. Im Portal legen Sie ihn im Entwicklerbereich an, markieren die benötigten Rechte und erhalten eine Adresse der Form https://<portal>/rest/<benutzer-id>/<token>/<methode>.json — die Autorisierung steckt in der Adresse selbst, der HTTP-Request-Node braucht also nichts außer diesem Link und Sorgfalt im Umgang damit. Methodenname und Parameter gehen genau so mit, wie es die Dokumentation beschreibt: crm.item.add, crm.item.update, tasks.task.add.

Zwei Eigenschaften dieser Adresse entscheiden über fast alles Spätere. Der Webhook arbeitet mit den Rechten des Mitarbeiters, der ihn angelegt hat: Ein Szenario, das eine Pipeline nicht sehen darf, scheitert an den Rechten, während das Token völlig gültig ist — legen Sie Webhooks deshalb unter einem Dienstkonto an und nicht unter dem, der gerade am Rechner saß. Und das Token erneuert sich nicht von selbst: Es lebt, bis jemand es löscht oder diesen Mitarbeiter deaktiviert. Daher die Bequemlichkeit — und der Preis eines Lecks. Die Mechanik beider Richtungen steht im Webhook-Leitfaden.

Wie starte ich ein n8n-Szenario aus Bitrix24?

Zwei Wege, die sich unterschiedlich verhalten. Ein ausgehender Webhook des Portals abonniert Ereignisse — Deal geändert, Lead angelegt — und ruft die Adresse Ihres Webhook-Nodes auf. Er feuert bei jedem passenden Ereignis, gleich ob die Änderung von einem Menschen, aus einem Import oder von einer anderen Integration kam. Der Inhalt kommt als Formulardaten und nicht als JSON an, weshalb der Node beim ersten Lauf einzelne Felder statt eines Bodys zeigt.

Der zweite Weg ruft n8n aus dem Prozess selbst. Die Regel HTTP-Anfrage GET/POST trifft die Adresse des Webhook-Nodes genau an der Stelle, die Sie gewählt haben, und schickt nur die Daten mit, die Sie schicken wollen. JSON aus Feldern erstellen baut den Inhalt aus Prozesswerten zusammen, ohne Anführungszeichen von Hand zu maskieren, und Wert aus JSON per Pfad extrahieren holt die Antwort von n8n zurück in den Prozess — mehr zum Umgang mit Antworten im Beitrag über JSON in Geschäftsprozessen. Wo die Zustellung nicht verloren gehen darf — Auftrag in die Fertigung, Dokument zur Unterschrift —, setzen Sie Zuverlässiger Webhook ein: Er wiederholt nach eigenem Zeitplan und meldet, wie viele Versuche nötig waren, statt nach dem ersten Fehlschlag zu schweigen.

Welche Hälfte des Szenarios bleibt besser im Portal?

Die Hälfte, die das Portal ohnehin nie verlässt. Eine Phase wechseln, ein Feld füllen, eine Aufgabe stellen, nach einer Bedingung verzweigen: Führt man das über ein externes Szenario, kauft man sich einen zusätzlichen Netzweg, einen zweiten Ort zum Debuggen und ein Kontingent, das man im Auge behalten muss — und sonst nichts. Die vernünftige Aufteilung: n8n verantwortet die Systeme draußen, das Portal seine eigenen Datensätze, dazwischen ein Aufruf. Was diese Entscheidung kostet, steht im Vergleich von Connectoren und Automatisierung im Portal; der Portalteil selbst ist gewöhnliche Einrichtung von Automatisierungsregeln.

Warum bleibt das Szenario stumm?

Zuerst die n8n-Seite: Der Webhook-Node hat zwei Adressen, eine zum Testen und eine für den Betrieb, und die Betriebsadresse antwortet nur bei aktivem Szenario — eine im Testmodus gebaute und geprüfte Verbindung verstummt genau dann, wenn niemand mehr zuschaut. Dann die Portalseite: Ein ausgehender Webhook, der am falschen Ereignis oder am falschen Entitätstyp hängt, erzeugt gar keine Anfrage; eine leere Ausführungsliste in n8n ist also eine Frage des Abonnements und nicht des Netzes.

Kommen die Anfragen an und antworten mit einem Fehler, lesen Sie den Text, statt erneut zu senden: fehlende Rechte des Webhooks, ein falscher Feldcode und ein überschrittenes Limit sehen alle nach „geht nicht“ aus, werden aber verschieden behoben. Das Limit gehört dabei gesondert in den Kopf — das Portal erlaubt wenige Aufrufe pro Sekunde, und eine Schleife über einige hundert Datensätze ohne Pausen läuft von allein hinein. Und wenn die Regel gar nicht erst angesprungen ist, mit der alles beginnen sollte, hilft die Übersicht warum Automatisierungsregeln nicht laufen.

Wie geht es weiter?

Zerlegen Sie Ihr Szenario in zwei Listen: Schritte, die externe Systeme berühren, und Schritte, die nur Portaldatensätze berühren. Die zweite Liste wandert nach innen — meist bleibt danach je ein Webhook pro Richtung übrig, und das lässt sich deutlich leichter am Leben halten. Die Bausteine für den Portalteil stehen im Katalog der Automatisierungsregeln, und fehlt der passende, beschreiben Sie die Aufgabe: Roboteka baut fehlende Regeln kostenlos und stellt sie in die gemeinsame Bibliothek.