Odoo gibt deiner Integration einen API-Call pro Sekunde. Alles andere folgt daraus.

Wer nach Rat zur Odoo-Integration sucht, findet zwei Sorten Seiten: Partner-Broschüren oder Tutorials, die zeigen, wie man search_read aus Python aufruft. Keine von beiden nennt das, was die Architektur tatsächlich entscheidet. Odoo veröffentlicht harte Grenzen für das, was eine externe Integration darf, und zwei davon haben ein Datum.

Dieser Text kommt von der Build-Seite, für das Team, das ein Produkt, ein Kundenportal, einen Shop, eine Preisengine oder ein internes Tool an eine Odoo-Datenbank hängen und über Odoos Release-Zug hinweg am Leben halten muss. Er setzt voraus, dass Odoo bleibt. Nichts hier ist ein Argument dafür, ein ERP zu ersetzen, das deine Buchhaltung längst trägt. Die einzige lohnende Frage ist, wo die Grenze zwischen Odoo und der Software liegt, die dir gehört, und Odoos eigene Dokumentation beantwortet den größten Teil davon, wenn du die richtigen fünf Seiten liest.

Die fünf Limits in einer Tabelle

Lies die letzten beiden Zeilen zusammen, denn genau dort tut es weh. Dein RPC-Client muss weg sein, bevor Odoo Online 21.1 erreicht, und das Upgrade dorthin kontrollierst du nicht vollständig.

Limit 1: die externe API ist ein Plan-Feature

Die erste Überraschung ist kommerziell, nicht technisch. Odoos JSON-2-API-Referenz schreibt, dass der Datenzugriff über die externe API nur in Custom-Preisplänen verfügbar ist und in One App Free oder Standard nicht.

Diese eine Notiz stellt viele Projekte um. Ein Unternehmen, das den Standard-Plan gewählt hat, weil er nach der vernünftigen Mitte aussah, hat ein ERP gekauft, mit dem die eigene Software nicht sprechen kann. Das Integrationsbudget muss dann einen Planwechsel für jeden Nutzer, jeden Monat, dauerhaft aufnehmen. Es ist das Billigste zum Prüfen und das Teuerste zum Entdecken in Woche sechs.

Zwei praktische Hinweise. Erstens: selbst gehostetes Odoo Community hat überhaupt kein Plan-Gate, weil es keinen Plan gibt, und das ist eines der wenigen echten Argumente dafür, es selbst zu betreiben. Zweitens: Plannamen und Stufen sind Marketingfläche und bewegen sich, behandle die Doku-Notiz also als Grund, deinen eigenen Vertrag zu prüfen, nicht als Zitat für ein Entscheidungsmemo.

Limit 2: ein Call pro Sekunde, und keine parallelen Calls

Odoo veröffentlicht keine Quote pro Endpunkt mit dokumentierter 429-Schwelle. Veröffentlicht wird eine Policy. Die Acceptable-Use-Policy für Odoo Cloud listet ungedrosselte RPC- und API-Calls als verbotenen Netzwerkmissbrauch, verweist darauf, dass es Batch-APIs für Importe gibt, und nennt gedrosselte Calls bei nicht dauerhafter Nutzung mit einer Rate von einem Call pro Sekunde und ohne parallele Calls typischerweise akzeptabel. Sie nennt auch die Ausstiegsluke: auf Odoo.sh kann dediziertes Hosting als Alternative gelten, um diese Beschränkung aufzuheben.

Eine Policy-Obergrenze ist schwerer zu designen als eine dokumentierte Quote, weil du dich nicht in Sicherheit messen kannst. Du musst annehmen, dass die Zahl die Zahl ist. Ein Call pro Sekunde, seriell, ergibt ein Budget von etwa 86.000 Calls pro Tag, wenn du jede Sekunde nutzt, was keine echte Integration tut. Die Frage verschiebt sich also von "wie schnell können wir" zu "wie wenige Calls braucht das".

Was das konkret an Calls spart

• Ein Roundtrip statt zwei. search_read ersetzt ein search plus read. Jede kombinierte ORM-Methode ist ein Call, den du nicht ausgegeben hast.
• In Odoo aggregieren. read_group liefert gruppierte Summen aus der Datenbank. 40.000 Auftragspositionen zu ziehen, um sie selbst zu summieren, ist dieselbe Antwort zum hundertfachen Preis.
• In Batches schreiben. Eine Liste von Ids an einen Write zu übergeben, ist ein Call. Eine Schleife über Ids ist ein Call pro Datensatz, und eine Schleife über 3.000 Datensätze ist ein selbst verursachter Ausfall.
• Nur die Felder anfragen, die du brauchst. Eine fields-Liste hält die Response klein und verhindert, dass dein Client von Spalten abhängt, die du nie wolltest. Das zahlt sich beim Upgrade erneut aus.
• Niemals für Change Detection pollen. Polling ist der größte Verbraucher eines Budgets von einem Call pro Sekunde, und es skaliert mit deiner Kundenzahl, nicht mit deinem Datenvolumen.

Der Ersatz für Polling ist schon im Produkt. Odoos Automatisierungsregeln enthalten die Aktion Send Webhook Notification, die die ausgewählten Felder eines Datensatzes an eine von dir angegebene URL postet, samt Vorschau des Payloads, und sie können auch von einem eingehenden Webhook eines externen Systems ausgelöst werden. Odoos eigene Doku hängt eine Warnung daran: hol Entwicklung oder Solution Architecture dazu, denn ein falsch konfigurierter Webhook kann die Datenbank stören. Diese Warnung ist berechtigt, und sie ist der Grund, warum Webhooks auf deiner Seite hinter eine Queue gehören und nicht direkt in Geschäftslogik.

Die Form, die überlebt, ist unspektakulär. Odoo pusht ein Event. Dein Service nimmt es an, schreibt es in den eigenen Store, antwortet schnell mit 200 und erledigt die eigentliche Arbeit asynchron, mit Retry-Policy und einem Rate-Limiter, der einen Call pro Sekunde respektiert. Dein Produkt liest aus deinem Store, nicht aus Odoo. Odoo bleibt System of Record für das, was ihm gehört.

Limit 3: jeder Call ist seine eigene Transaktion

Das ist das Limit, das die teure Fehlerklasse produziert, und es steht klar im Transaktionsabschnitt der JSON-2-Referenz: alle Calls an den JSON-2-Endpunkt laufen in ihrer eigenen SQL-Transaktion, bei Erfolg committed, bei Fehler verworfen, und es ist nicht möglich, mehrere Calls in einer Transaktion zu verketten. Die Doku geht weiter und schreibt, dass die Datenbank zwischen deinen Calls von anderen gleichzeitigen Transaktionen verändert werden kann, und dass das besonders gefährlich ist bei Operationen rund um Reservierungen und Zahlungen.

Lies das als Architekturanweisung, denn genau das ist es. Odoos empfohlene Lösung steht im gleichen Absatz: rufe immer eine einzige Methode auf, die alle zusammenhängenden Operationen in einer Transaktion ausführt, und wenn es keine solche Methode gibt, erstelle eine in einem eigenen Modul.

Damit lautet die ehrliche Antwort auf "geht das, ohne Odoo-Code anzufassen" oft nein. Eine Dreier-Sequenz, die Bestand prüft, reserviert und den Auftrag bestätigt, ist keine Transaktion. Es sind drei Transaktionen mit zwei Fenstern, in denen ein anderer Nutzer, eine andere Integration oder eine geplante Aktion die Welt unter dir verändern kann. Der Fehler ist kein Crash. Es sind eine doppelte Reservierung, eine Zahlung gegen einen veralteten Preis oder eine Auftragsposition ohne Kopf, entdeckt von der Buchhaltung einen Monat später.

Drei Regeln für jeden Odoo-Schreibpfad

1. Eine Geschäftsoperation, ein Call. Hat die Operation eine Invariante, bekommt sie eine Methode in einem Custom-Modul, und dein Service ruft genau diese eine Methode. Die Invariante lebt in der Datenbanktransaktion, nicht in deinem Orchestrierungscode.
2. Idempotenzschlüssel auf allem, was anlegt. Deine Retry-Policy wird einen Call erneut senden, dessen Response du nie gesehen hast. Speichere deinen eigenen Schlüssel am Odoo-Datensatz, prüfe ihn vor dem Anlegen, und ein Retry wird zum No-op statt zur Doppelrechnung.
3. Abgleichen, nicht vertrauen. Ein nächtlicher Job, der deinen Store gegen Odoo über wenige aggregierte Reads vergleicht, fängt die Drift, die Fehlerbehandlung pro Call übersieht. Billig in Calls, und das Einzige, was die Fehler findet, die niemand geloggt hat.

Limit 4: das RPC-Protokoll hat ein Enddatum

Fast jede bestehende Odoo-Integration draußen spricht XML-RPC, weil das viele Jahre die Antwort war. Die External-RPC-API-Referenz beginnt jetzt mit einem Entfernungshinweis: sowohl die XML-RPC- als auch die JSON-RPC-API an /xmlrpc, /xmlrpc/2 und /jsonrpc sollen in Odoo 22 (Herbst 2028) und Odoo Online 21.1 (Winter 2027) entfernt werden, die External JSON-2 API ist der Ersatz. Alle drei angebotenen Services, common, db und object, sind deprecated. Interne Controller mit @route(type='jsonrpc') sind ausdrücklich nicht betroffen.

Zwei Daten, und welches dich bindet, hängt davon ab, wo deine Datenbank liegt. Odoo Online erreicht die Grenze zuerst, im Winter 2027, weil Odoo Online Minor-Versionen ausliefert und sich schneller bewegt als die Major-Linie. Selbst gehostete und Odoo.sh-Datenbanken haben bis Odoo 22 im Herbst 2028, plus so lange, wie du auf einer nicht unterstützten Version sitzen willst.

Die Migration selbst ist klein, wenn dein Call-Layer ein Modul ist, und schmerzhaft, wenn RPC-Calls über den Code verstreut sind. Was sich ändert:

Die Änderung bei der Authentifizierung ist die, die du planen und nicht mechanisch portieren solltest. JSON-2-Keys lassen sich über res.users.apikeys programmatisch erstellen, widerrufen und rotieren, mit einem Ablaufdatum, das gegen die maximal erlaubte Key-Dauer der Rollen des Nutzers validiert wird. Odoos Empfehlung ist, automatisierte Integrationen unter einem dedizierten Bot-Nutzer mit minimalen Rechten und leerem Passwort zu betreiben, damit der Login-Weg geschlossen ist und das Access-Log den Bot nennt statt eine Person zu imitieren. Mach das einmal pro Integration, und Key-Rotation wird zur Ops-Aufgabe statt zur Migration.

Limit 5: die Upgrade-Uhr gehört Odoo

Die Upgrade-Dokumentation ist die Seite, die die meisten Integrationspläne überspringen, und sie enthält die Einschränkung mit dem längsten Schweif. Jede Major-Version wird drei Jahre unterstützt. Bei Odoo Online ist ein Upgrade alle zwei Jahre für eine Major-Version verpflichtend und wenige Wochen nach dem nächsten Release für eine Minor-Version, wobei Minor-Versionen etwa alle zwei Monate erscheinen. Odoos Upgrade-Team fährt für jede fällige Datenbank ein stilles Testupgrade, und wenn das gelingt und unter zwanzig Minuten dauert, läuft das automatische Upgrade, sofern du nicht vor der Deadline handelst.

Dann die zwei Sätze, die entscheiden, wer die Kosten trägt. Eine Datenbank mit Custom-Modulen lässt sich erst upgraden, wenn eine Version dieser Module für die Zielversion existiert. Und wenn eine Änderung in einer neuen Version eine Anpassung bricht, liegt die Verantwortung für die Kompatibilität beim Maintainer dieses Custom-Moduls. Odoos eigene Testcheckliste setzt Integrationen mit externer Software, APIs und EDI an die erste Stelle.

Das ist keine Beschwerde über Odoo. Es ist der Deal, und es ist ein vernünftiger Deal. Aber es bedeutet, dass jedes Custom-Modul und jede Integration laufende Kosten mit einem Namen daran hat, und der Name muss eine echte Person oder ein echter Vertrag sein. Version 19 macht das konkret: res.users.groups_id heißt im 19.0-Quellcode group_ids, und das separate Vertragsmodell ist als hr.version in den HR-Kern gewandert. Jeder externe Client, der diese Felder benannt hat, liefert je nach Call eine saubere 200 mit falscher Form oder einen Fehler. Beides fängt keine Testsuite, die Odoo mockt.

Die billige Verteidigung ist ein Contract-Test: eine kleine Suite, die deine echten Read- und Write-Pfade gegen eine upgegradete Kopie der Datenbank fährt und auf die Felder prüft, von denen du tatsächlich abhängst. Dieselbe Disziplin wie bei jeder anderen API, die du nicht kontrollierst, und sie macht aus dem verpflichtenden Upgrade-Fenster einen Vormittag statt einer Feuerübung.

Wo Hosting die Diskussion entscheidet

Drei der fünf Limits werden davon bestimmt, wo die Datenbank läuft. Damit ist Hosting eine Architekturentscheidung und keine Beschaffungsentscheidung.

Eine Lizenztatsache ist hier wichtig und wird regelmäßig geraten. Der Odoo-Community-Quellcode steht unter der LGPL Version 3, weshalb ein proprietäres Custom-Modul auf Community normale Praxis und kein juristisches Argument ist. Enterprise-Editionen und Odoos eigene gehostete Pläne haben separate kommerzielle Bedingungen, lies die also gegen deinen Fall statt eine Meinung aus einem Forenthread zu übernehmen.

Selbst hosten ist nicht gratis. Du kaufst die Aufhebung einer Rate-Obergrenze mit Backups, Upgrades, Monitoring, einem Reverse Proxy, den du jetzt selbst drosselst, und jemandem in Rufbereitschaft. Dieser Tausch ist derselbe wie in unserem Leitfaden zu individueller Software gegenüber Standardsoftware: bezahle für das, was deine Geschäftslogik wirklich berührt, und konfiguriere den Rest.

Die Referenzform, die wir bauen

Jede Odoo-Integration, die wir gesehen haben, konvergiert auf dieselbe Architektur, sobald die fünf Limits auf dem Tisch liegen. Es ist ein Service, der deinem Team gehört und zwischen Odoo und allem anderen sitzt.

1. Ein Anti-Corruption-Layer. Ein Modul in deinem Code kennt Odoos Modellnamen, Feldnamen und Eigenheiten. Nichts anderes im Produkt importiert es. Wenn groups_id zu group_ids wird, änderst du eine Datei.
2. Ein eigener Read-Store. Was dein Produkt im heißen Pfad liest, liegt in deiner Datenbank, gefüllt durch Events und periodisch abgeglichen. Produktlatenz hängt nicht länger an einem ERP unter Call-Obergrenze.
3. Ein Webhook-Endpunkt mit Queue. Annehmen, persistieren, 200 zurückgeben, asynchron verarbeiten, mit Backoff wiederholen. Odoos Automatisierungsregel ist der Producer, deine Queue schluckt Bursts, die ein synchroner Handler verwerfen würde.
4. Ein Writer mit einer einzigen Spur. Ein einziger serialisierter Worker erzwingt das Call-Budget an einer Stelle, trägt Idempotenzschlüssel und gibt dir ein Dashboard für das gesamte Call-Volumen der Integration.
5. Custom-Modul-Methoden für Invarianten. Kleine, benannte, transaktionsgebundene Methoden für Operationen, die nicht zerreißen dürfen. Reviewt und versioniert wie Produktcode, denn beim Upgrade sind sie deine Verpflichtung.
6. Contract-Tests gegen eine echte upgegradete Datenbank. Das Gate, das Odoos Upgrade-Zeitplan überlebbar macht.

Die nächste Analogie in unserer eigenen Arbeit ist gar kein ERP. Im MyMerch-Projekt zur Prozessautomatisierung lief beim Kunden ein funktionierender Commerce-Betrieb über viele Storefronts, und an zwei konkreten Stellen ging Marge verloren. Der verlockende Vorschlag wäre ein Rewrite gewesen. Funktioniert hat: die manuellen Übergaben benennen, diese automatisieren und die Plattform in Ruhe lassen. Derselbe Instinkt gilt für ein ERP: der Wert liegt an der Integrationsgrenze, und die Plattform darunter ist meistens in Ordnung. Die allgemeine Version dieses Arguments haben wir in Architektursanierung ohne Rewrite aufgeschrieben.

Vier Dinge, die wir nicht tun würden

• Odoo nicht in Echtzeit spiegeln. Eine bidirektionale Synchronisation geteilten veränderlichen Zustands über eine Leitung mit einem Call pro Sekunde ist ein Distributed-Systems-Projekt im Integrationskostüm. Wähle pro Feld einen Schreiber und bleib dabei.
• Die Kernbuchhaltung nicht ins Produkt ziehen. Sobald Rechnungen, Steuerlogik oder der Kontenplan in zwei Systemen leben, gehört dir der Abgleich für immer. Wenn eine gesetzliche Pflicht dich dorthin drückt, ist die Antwort meist eine Schicht neben dem ERP statt in deiner App, und genau das war unser Schluss zu strukturierter E-Rechnung rund um einen Payment-Provider.
• Keine Geschäftslogik in Automatisierungsregeln. Serveraktionen und Codeblöcke im UI sind unsichtbar für Code-Review, ungetestet und unversioniert. Sie sind exzellenter Kleber und ein schlechter Ort für Regeln, an denen Geld hängt.
• Die Integration darf nicht niemandes Modul sein. Undokumentierte, herrenlose Odoo-Anpassungen sind der häufigste Grund, warum ein Upgrade stehen bleibt, und das Häufigste, was ein neuer Dienstleister blind erbt. Unsere Checkliste für diese Übergabesituation steht in Softwareprojekt von einem anderen Anbieter übernehmen.

Ein 30-Tage-Plan von unklar zu sicher

1. Tag 1 bis 3, Fakten feststellen. Hostingart, exakte Version, Planstufe und ob die externe API vertraglich verfügbar ist. Dann jede bestehende Integration listen und welches Protokoll sie spricht. Den letzten Punkt können die meisten Teams am ersten Tag nicht beantworten.
2. Tag 4 bis 10, Call-Volumen messen. Eine Woche jeden ausgehenden Call loggen, gruppiert nach Aufrufer und Zweck. Die Polling-Jobs stehen oben auf dieser Liste und fallen zuerst.
3. Tag 11 bis 18, Invarianten benennen. Jede Operation aufschreiben, die alles oder nichts sein muss. Jede wird eine einzelne Custom-Modul-Methode mit Test, oder ein akzeptiertes Risiko mit einem Abgleichjob dahinter.
4. Tag 19 bis 25, die Grenze bauen. Ein Anti-Corruption-Modul, ein serialisierter Writer mit Idempotenzschlüsseln, ein Webhook-Endpunkt mit Queue. In diesem Fenster keine neuen Features.
5. Tag 26 bis 30, JSON-2-Umstellung planen. Ein datierter Plan, gebunden an dein eigenes Upgrade-Fenster und nicht an 2027. Ein dedizierter Bot-Nutzer, API-Keys pro Integration mit Ablauf und ein Rotations-Runbook.

Dreißig Tage setzen voraus, dass jemand die Entscheidungen besitzt. Fehlt dieser Jemand, bleibt die Arbeit bei Schritt zwei stehen, und das ist ein häufiger Grund, warum Firmen für ein begrenztes Integrationsprogramm einen Fractional CTO holen statt dafür einzustellen.

Primärquellen

• Odoo-19-Dokumentation, External JSON-2 API, inklusive Planbeschränkung, API-Key-Verwaltung und Transaktionsabschnitt
• Odoo-19-Dokumentation, External RPC API, mit dem Entfernungshinweis für die XML-RPC- und JSON-RPC-Endpunkte
• Odoo Acceptable-Use-Policy, Netzwerk- und Servicemissbrauch, zu gedrosselten Call-Raten
• Odoo-19-Dokumentation, Upgrade, zu Supportdauer, verpflichtenden Upgrades, Rolling Release und Verantwortung für Custom-Module
• Odoo-19-Dokumentation, Automatisierungsregeln, inklusive der Aktion Send Webhook Notification
• Odoo-19.0-Quellcode, res.users, mit dem Feld group_ids
• Odoo-19.0-Quellcode, das Modell hr.version im HR-Kern
• Odoo-19.0-LICENSE-Datei, LGPL Version 3 für den Community-Quellcode