n8n und Odoo: Was sich per Workflow automatisieren lässt und was ein Modul braucht

n8n eignet sich für alles, was rund um Odoo passiert: ein externes Formular entgegennehmen, einen Chat benachrichtigen, einen Tagesbericht zusammenstellen. Was den Geschäftsstatus innerhalb von Odoo verändert (Preise, Bestandsreservierungen, Lieferschein-Validierungen, Zahlungsabstimmung), braucht ein Modul. Die Grenze zeigt sich, wenn man beides gegen ein echtes Odoo ausführt: Dieser Artikel stammt aus einem eigenen Labor mit Odoo 19.0-20260630 und n8n 2.30.6.

Wie n8n mit Odoo spricht: vier Wege, nicht einer

• XML-RPC: /xmlrpc/2/common zur Authentifizierung und /xmlrpc/2/object für execute_kw. Der Weg aus der Dokumentation.
• JSON-RPC: ein POST /jsonrpc mit service, method und args. Derselbe Dienst in JSON.
• Websitzung: /web/session/authenticate und /web/dataset/call_kw mit dem Cookie. Das, was Ihr Browser tut.
• Die JSON-2-API, nur in Odoo 19: POST /json/2/<modelo>/<método> mit Authorization: bearer <clave API> und X-Odoo-Database. Ohne Sitzung: Die Argumente werden als benannte Felder übergeben, einschließlich context.

# Sesion + call_kw: funciona igual en 17, 18 y 19.
POST /web/session/authenticate
 {"params":{"db":"lab","login":"n8n_bot2","password":"..."}}
-> 200 {"result":{"uid":6,"server_version":"19.0-20260630"}}   # + cookie

POST /web/dataset/call_kw          # con esa cookie
 {"params":{"model":"crm.lead","method":"create",
            "args":[{"name":"Lead web","type":"lead"}],
            "kwargs":{"context":{"lang":"es_ES"}}}}
-> 200 {"result": 10}

# Clave API en la cabecera, sin sesion: solo Odoo 19.
POST /json/2/crm.lead/create
Authorization: bearer <clave>     X-Odoo-Database: lab
 {"vals_list":[{"name":"Lead via /json/2 (API key)"}]}
-> 200 [9]

# Sin cabecera -> 401 "User not authenticated, use an API Key with a
#                 Bearer Authorization header."
# Metodo privado -> 403 "Private methods (such as
#                 'crm.lead._compute_display_name') cannot be called remotely." 

Der Odoo-Knoten von n8n 2.30.6 wählt anhand der Zugangsdaten für Sie aus: Die mit API-Schlüssel läuft über /json/2; die klassische läuft über /jsonrpc mit execute, positionsbasiert, das kwargs nicht akzeptiert und keinen Kontext übergeben kann. Die Zugangsdaten mit API-Schlüssel weisen zudem darauf hin, dass sie «Odoo 19+ and a Custom pricing plan» erfordern.

Der HTTP-Request-Knoten, genau so, wie er entstanden ist

Beachten Sie, wo der Schlüssel nicht steht: Der Body enthält nur Daten, und der Header Authorization wird von einer n8n-Zugangsdatenverwaltung gesetzt, die verschlüsselt und separat rotiert wird.

// Lineas del nodo real, copiadas de `n8n export:workflow`.
"type": "n8n-nodes-base.httpRequest", "typeVersion": 4.2,
"url": "http://odoo:8069/json/2/crm.lead/create",
"authentication": "genericCredentialType",
"genericAuthType": "httpHeaderAuth",
"headerParameters": { "parameters": [
    { "name": "X-Odoo-Database", "value": "lab" } ] },
"jsonBody": "={{ JSON.stringify({ vals_list: [{ name: 'Web: ' + $json.body.empresa, contact_name: $json.body.nombre, email_from: $json.body.email, description: $json.body.mensaje, type: 'lead' }] }) }}",
"credentials": { "httpHeaderAuth": { "name": "Odoo lab - API key (header)" } }
// La clave no esta aqui: la pone esa credencial.

Der Workflow meldet sich außerdem nicht als Administrator an, sondern als technischer Benutzer mit genau den nötigen Gruppen und der Obergrenze, die Odoo 19 für dessen Schlüssel setzt:

# Usuario tecnico nuevo (solo grupo de usuario interno):
POST /json/2/crm.lead/create
-> 403 "No puede crear informes 'Lead' (crm.lead) ...
            - Sales/Administrator
            - Sales/User: Own Documents Only"
# Tras anadirle sales_team.group_sale_salesman:  -> 200

# Su clave API tampoco dura lo que uno quiera:
_generate(..., +200 dias) -> "No puede exceder 90.0 dias."
_generate(..., sin fecha) -> "La clave API debe tener una
                              fecha de vencimiento"

Diese Obergrenze von 90 Tagen ist das Datum, an dem Ihr Workflow aufhört zu funktionieren, ohne dass jemand etwas anfasst. Notieren Sie es am Tag, an dem Sie den Schlüssel erstellen.

Fünf Automatisierungen, die in einen Workflow passen

Allen gemeinsam ist: Der Vorgang ist bereits geschehen, und der Workflow verschiebt ihn nur an einen anderen Ort.

Der zweite Fall hat ein Kleingedrucktes. Die Webhook-Aktion sendet _model, _id und den Namen der Aktion und arbeitet nach dem Prinzip «Fire and forget»: ein POST von einer Sekunde, ohne Wiederholung. In 19 wird sie nach dem Commit gesendet; in 17 und 18 läuft sie innerhalb der Transaktion, sodass ein langsames n8n den Benutzer ausbremst.

# Accion de servidor state='webhook' al crear un lead.
INFO    Webhook call to http://n8n:5678/webhook/odoo-lead
INFO    Webhook call to http://n8n:5678/webhook/odoo-lead - succeeded

# Apuntando a un flujo borrado (el lead se crea igual):
WARNING Webhook call failed: 404 Client Error: Not Found for url:
        http://n8n:5678/webhook/flujo-borrado
WARNING Webhook call timed out after 1s - it may or may not have failed.

Fünf, die nicht passen, und der genaue Grund

1. Preise oder Rabatte berechnen. Odoo berechnet sie aus der Preisliste; wenn der Workflow sie extern berechnet, gibt es bei einer Preislistenänderung zwei Wahrheiten.
2. Bestand für mehrere Kanäle reservieren. Odoo löst das Wettrennen innerhalb einer Transaktion; ein Workflow, der getrennt liest, entscheidet und schreibt, verkauft zu viel.
3. Zahlungen abstimmen. Zuordnen und Verbuchen gehören zusammen: Wird das eine außerhalb und das andere innerhalb erledigt, hinterlässt ein Netzausfall eine halbe Abstimmung.
4. Alles, was jemand prüfen wird. Der Verlauf von n8n ist nicht der Chatter: «Wer hat das geändert und warum?» wird im Dokument beantwortet.
5. Alles, was von einem Feld abhängt, das sich zwischen Versionen ändert. Wir haben das geprüft, indem wir in Odoo 19 schrieben, was in 18 funktionierte.

Der Fall, der es am besten zusammenfasst: einen Lieferschein aus einem Workflow validieren. Wir haben einen mit 10 Einheiten vorbereitet, von denen 4 reserviert waren, und button_validate aufgerufen, dasselbe wie die Schaltfläche.

# WH/OUT/00003: 10 pedidas, 4 reservadas.
POST /web/dataset/call_kw
 {"model":"stock.picking","method":"button_validate","args":[[2]]}
-> 200 {"result": {"name": "¿Crear entrega parcial?",
                   "type": "ir.actions.act_window",
                   "res_model": "stock.backorder.confirmation", ...}}

read -> [{"name":"WH/OUT/00003","state":"assigned"}]   # sigue abierto

HTTP 200, kein Fehler, und ein Lieferschein in assigned. Für n8n ist der Schritt grün; für das Lager ist die Bestellung nicht hinausgegangen. Ein Modul erkennt den Assistenten und hält es im Dokument fest: dieselbe Grenze wie bei Odoo 19 gegenüber Middleware-Konnektoren.

Und die Felder, die zwischen Versionen ihren Namen ändern, was einen stabilen Workflow nach einer Migration bricht:

# Odoo 19, escribiendo lo que funcionaba en 17 y 18:
res.users write {"groups_id": [[4, 1]]}
-> "Invalid field 'groups_id' in 'res.users'"     # en 19 se llama group_ids

stock.move create {"name": "Latiguillo", "product_id": 1, ...}
-> "Invalid field 'name' in 'stock.move'"         # en 17 y 18 era obligatorio

Wir pflegen denselben Code in Odoo 19, 18 und 17 in 105 veröffentlichten Modulen: Diese Unterschiede trägt das Modul, nicht der Kunde. Das ist auch die Grenze von Odoo Studio, wenn der Prozess nicht mehr ein Feld ist, sondern zu einer Regel wird.

Die vier Fehler, die wir immer wieder sehen

1. Die Schleife. Eine Automatisierung benachrichtigt n8n bei Änderung eines Felds, der Workflow schreibt in Odoo, und das Geschriebene löst sie erneut aus. Sie wird mit einer Bedingung im Auslöser unterbrochen.
2. Zugangsdaten im Klartext. Weder im Body des Knotens noch in einem Code-Knoten: in einer n8n-Zugangsdatenverwaltung, mit einem technischen Benutzer mit minimalen Gruppen.
3. Keine Idempotenz. Ein von der Gegenseite wiederholter Webhook legt den Datensatz erneut an: Drei identische POST an unseren Workflow ergaben drei Leads.
4. Keine echte Wiederholung. Ein Knoten wiederholt nur, wenn Sie Retry On Fail aktivieren, und die Engine begrenzt die Versuche auf fünf und die Wartezeit auf fünf Sekunden. Das reicht für einen Chat; nicht für einen Zusteller: Unser Modul für Correos Express wiederholt nach 5, 15, 30, 60, 120 und 240 Minuten.

Die Lösung liegt nicht bei n8n, sondern im Design: Speichern Sie in Odoo die externe Referenz und prüfen Sie sie vor dem Anlegen. In einem Modul ist das eine eindeutige Einschränkung in der Datenbank; in einem Workflow ein vorheriges Lesen mit Wettlauf-Fenster.

Wann ein Workflow zum Modul wird

Der Workflow ist ein günstiger Weg herauszufinden, ob der Prozess es wert ist zu existieren. Das Signal, dass er zu kurz greift, ist eines dieser sechs:

• Er schreibt ein Feld, das Odoo selbst berechnet.
• Zwei Schreibvorgänge müssen gemeinsam stattfinden oder gar nicht.
• Jemand wird in Odoo prüfen, was wann geschehen ist.
• Der Prozess muss die nächste Migration überleben.
• Der Aufruf muss wiederholbar sein, ohne etwas zu duplizieren.
• Der Benutzer muss direkt im Dokument erneut versuchen können.

An diesem Punkt wirft man den Workflow nicht weg: Man verlagert den Teil, der den Geschäftsstatus berührt, ins Modul, und n8n behält den Rand. Das ist genauso bei der Automatisierung von Verwaltungsaufgaben und bei der Integration mit Signaturit.

Häufig gestellte Fragen

Nützliche Links innerhalb von FlexigoTech

Was wir dazu anbieten