+31 20 730 3200 Kontakt aufnehmen
Headless ERP

Headless ERP: welche Systeme das wirklich können

Jeder Anbieter sagt, sein ERP sei offen. Die entscheidende Frage ist enger: kann eine öffentliche Website daraus lesen, bei echtem Traffic, ohne dass der Anbieter bestimmt, wann Schluss ist.

Was ist ein Headless-ERP?

Ein Headless-ERP ist ein ERP, das Sie rein als Daten- und Logikschicht nutzen, mit einer separat darauf gebauten Oberfläche. Ihre Website, Ihr Portal oder Ihre App spricht über die API mit dem ERP, während das ERP selbst keine Seiten ausliefert. Der Reiz: eine einzige Quelle der Wahrheit für Preise, Bestände und Kunden, ohne das eigene Frontend des ERP zu erben, das meist langsam und schwer zu gestalten ist. Der Haken: die meisten ERP-Systeme erlauben das technisch und praktisch nicht, wegen dessen, was ihre API erreichen darf, und wie stark sie gedrosselt wird.

Warum "wir haben eine API" fast nichts aussagt

Fragen Sie einen beliebigen ERP-Anbieter, ob sein System offen ist, und die Antwort lautet ja. Es gibt eine API, es gibt Dokumentation, vielleicht sogar ein Entwicklerportal. Nichts davon beantwortet Ihre eigentliche Frage, nämlich ob Sie eine Website davorsetzen können und in zwei Jahren noch laufen.

Drei Dinge entscheiden das, und Anbieter stellen sie selten nebeneinander. Erstens die Reichweite: kommen Sie an jedes Objekt im System heran oder nur an das, was jemand freigegeben hat? Zweitens die Decke: wie viele Aufrufe dürfen Sie machen, bevor abgeschaltet wird, und wächst diese Decke mit Ihrem Traffic oder mit Ihrer Lizenz? Drittens die Eigentümerschaft: wenn die Decke zu niedrig ist, können Sie sie selbst anheben oder müssen Sie fragen?

Diese drei bewertet die Matrix unten. Es ist kein Urteil über das ERP als ERP. Exact Online ist ein starkes Buchhaltungspaket, und AFAS sitzt nicht ohne Grund tief in der niederländischen Personalwirtschaft. Hier geht es nur darum, ob das System hinter einem öffentlichen Frontend stehen kann.

Drei Wege, nicht zwei

Die Diskussion tut meist so, als gäbe es zwei Optionen: das ERP rendert Ihre Website, oder Sie gehen vollständig headless. In der Praxis gibt es einen dritten, und den wählen die meisten Unternehmen: eine spezialisierte Plattform davorsetzen, etwa Shopify oder WooCommerce für Commerce, und diese an das ERP anbinden.

  1. Das ERP rendert die Website

    Odoo Website oder das Äquivalent in Ihrem ERP

    + Ein System, keine Anbindung zu pflegen, die Redaktion bleibt dort, wo sie ohnehin arbeitet.

    - Sie erben dessen Frontend. Unsere Messung: im Median rund 1,5 MB JavaScript und CSS, bevor etwas nutzbar ist, grösstenteils der ERP-Web-Client, den Ihre Website nie benutzt.

  2. Eine spezialisierte Plattform vor dem ERP

    Shopify, WooCommerce oder ähnlich, ERP dahinter

    + Bewährter Commerce, ein grosses Plugin-Ökosystem und Konnektoren, die es fertig gibt. Für reine Webshops ist das oft wirklich die richtige Antwort.

    - Sie erben deren Frontend und deren Grenzen. Ihr Verhältnis von Inhalt zu Code ist das, was die Plattform liefert, und ein Konfigurator oder Lead-Magnet wird zur Frage, welches Plugin existiert, statt was Sie bauen wollen.

  3. Echt headless

    Ihr eigenes Frontend, ERP als Datenschicht

    + Volle Kontrolle über Struktur, Gewicht und Werkzeuge. Rechner, Konfiguratoren und Lead-Magnete entwerfen Sie, statt danach zu suchen.

    - Sie bauen es selbst und besitzen Caching und Upgrade-Pfad. Überdimensioniert für eine Website aus wenigen statischen Seiten.

Das strategische Problem des mittleren Weges ist nicht technisch. Wenn Ihre Wettbewerber alle auf denselben Marktführer standardisiert sind, konkurrieren Sie auf einer Plattform, die Ihnen allen dieselbe Decke gibt. Sie können kein Verhältnis von Inhalt zu Code gewinnen, das die Plattform nicht zulässt, und Sie können nicht ohne Weiteres das eine Werkzeug bauen, das Sie unterscheiden würde. Sich bei der Auffindbarkeit abzuheben, während Sie denselben Stack fahren wie alle anderen, ist sehr schwer.

Was wir selbst gemacht haben, und was es gebracht hat

Wir sind Odoo Gold Partner und haben unsere eigene Website bewusst nicht in Odoo gebaut. Das ist eine unbequeme Position, also hier, was passiert ist.

Die neue Website ging Anfang Juni 2026 live. Die Impressionen stiegen von rund 800 auf etwa 2.500 pro Tag, mehr als das Dreifache, und die Klicks von etwa elf auf neunzehn pro Tag.

Die ehrliche Einschränkung: wir haben im selben Zeitraum viel neuen Inhalt veröffentlicht, das ist also nicht die Plattform allein. Inhalt und Plattform lassen sich hier nicht trennen. Sagen können wir: derselbe Inhalt hätte im ERP-Website-Modul nie diese Geschwindigkeit und Struktur bekommen, und die Werkzeuge, die wir bauen konnten, weil uns das Frontend gehört, sind ein Teil davon, warum es funktioniert. Ausserdem ist es noch früh: Google ist mit der Neuindexierung nicht fertig, das Bild ist also nicht endgültig.

Search Console, Tagesdurchschnitt

  • Impressionen ~800 ~2.500
  • Klicks ~11 ~19

Die drei Prüfungen

Das bewertet die Matrix, jeweils auf einer Skala von null bis zwei.

  1. Reichweite

    Können Sie jedes Objekt lesen und schreiben, oder nur das, was eine Administratorin freigegeben hat? Ein ERP, in dem jemand vorab jede Sicht definieren muss, ist gut für Reporting und lästig für eine Website, weil jede neue Seite mit einer Anfrage an jemand anderen beginnt.

  2. Decke

    Wie viele Aufrufe, bevor gedrosselt wird, und wächst diese Decke mit dem Traffic oder mit dem, was Sie zahlen? Ein hartes Tageslimit ist der Unterschied zwischen einer Website, die mitskaliert, und einer, die an einem starken Tag stehen bleibt.

  3. Eigentümerschaft

    Wenn die Decke zu niedrig ist, können Sie sie selbst anheben? Auf einem selbst gehosteten System ist das Limit eines, das Sie setzen. Auf einem reinen Cloud-System ist das Limit eine kommerzielle Entscheidung von jemand anderem.

Welche ERP-Systeme wirklich headless können

Bewertet nach den drei Prüfungen oben, sortiert nach Gesamtwert. Wir bauen auf Odoo, lesen Sie die oberste Zeile also mit diesem Wissen; die zugrunde liegenden Zahlen sind von den Anbietern selbst dokumentiert und unten belegt.

ERP API Reichweite Decke Eigentümerschaft Urteil
Odoo Vollzugriff auf jede öffentliche Modellmethode einschliesslich der generischen ORM. Kein Limit auf Anwendungsebene: das setzen Sie selbst am Proxy, denn eine ungeschützte Instanz geht in die Knie. Open Source, also selbst hostbar. XML-RPC, JSON-RPC, JSON-2 ●● ●● ●● Geeignet
SAP Business One Die Service Layer erschliesst das Objektmodell breit. Kein veröffentlichtes Limit pro Minute; Batch-Operationen sind oberhalb von rund 300 Datensätzen eingeschränkt. Kann auf eigener Infrastruktur laufen. Service Layer (OData) ●● ●○ ●● Machbar, mit Einschränkungen
Microsoft Dynamics 365 BC 6.000 Anfragen pro fünf Minuten je Nutzer und fünf gleichzeitige Verbindungen, was grosszügig ist. Nur Cloud, die Decke gehört also nicht Ihnen. OData / API pages ●● ●○ ○○ Eher nicht
NetSuite Breiter Zugriff, aber die Gleichzeitigkeit richtet sich nach Ihrem Service Tier und der Zahl der SuiteCloud-Plus-Lizenzen. Die Decke ist eine kommerzielle Grösse. SuiteTalk SOAP/REST, RESTlets ●● ●○ ○○ Eher nicht
Exact Online 60 Aufrufe pro Minute und 5.000 pro Tag, je Verwaltung. Dieses Tageslimit ist die bindende Grenze: Sie erreichen es früher als Ihren Traffic. REST ●○ ○○ ○○ Eher nicht
AFAS Daten sind nur über GetConnectors und UpdateConnectors erreichbar, die eine Administratorin zuerst in AFAS definiert. Hervorragend für kontrollierte Anbindungen, unpraktisch, wenn eine Website ein Feld braucht, das noch niemand freigegeben hat. GetConnector / UpdateConnector ○○ ●○ ○○ Eher nicht

Zwei ist gut, eins ist machbar, null ist ein Hindernis.

Limits aus der Anbieterdokumentation, geprüft im Juli 2026: Odoo External API Reference, Exact Online API-Limits, Microsoft Learn zu Business-Central-API-Limits, Oracle NetSuite Concurrency Governance, AFAS-Connector-Dokumentation und SAP Business One Service Layer. Limits ändern sich; prüfen Sie sie erneut, bevor Sie etwas darum herum entwerfen.

Eine Sache zu Odoo, die Sie vor dem Bauen wissen sollten

Die klassischen XML-RPC- und JSON-RPC-Endpunkte entfallen in Odoo 22 (Herbst 2028) und Odoo Online 21.1 (Winter 2027) und werden durch die External JSON-2 API ersetzt. Was Sie heute bauen, sollte auf diese neue API zielen. Wir erwähnen es, weil genau solche Details leicht aus einem Verkaufsgespräch fallen und im Nachhinein teuer sind.

Was Headless Sie ehrlicherweise kostet

Headless ist keine kostenlose Architektur. Sie übernehmen Arbeit, die der Anbieter zuvor für Sie erledigt hat, und das zeigt sich an drei Stellen.

Sie besitzen jetzt das Frontend. Niemand liefert Ihnen mit dem nächsten Release ein Template. Jede Seite, jedes Formular und jeder Zustand, den Ihr ERP erzeugen kann, muss irgendwo existieren, das Sie gebaut haben. Für eine Unternehmenswebsite sind das ein paar Wochen; für ein vollständiges Kundenportal ist es ein Projekt.

Sie besitzen jetzt das Caching. Ein ERP ist nicht dafür gebaut, tausend anonyme Anfragen pro Minute zu beantworten, und selbst ohne veröffentlichtes Limit sollten Sie sich verhalten, als gäbe es eines. Preise und Bestände werden gecacht, Cache-Invalidierung wird zu etwas, worüber Sie nachdenken müssen, und "warum steht der Preis von gestern auf der Seite" wird zu einer Frage, die Sie beantworten können müssen.

Und Sie besitzen jetzt den Upgrade-Pfad. Die API, gegen die Sie bauen, wird sich ändern. Odoo hat bereits angekündigt, dass die klassischen XML-RPC- und JSON-RPC-Endpunkte verschwinden, und genau so etwas tut nur weh, wenn man nicht aufgepasst hat. Das ist machbar, aber es ist echte Arbeit, und ein Partner, der Ihnen erzählt, Headless habe nur Vorteile, hat noch nicht lange genug eines betrieben.

Häufige Fragen zu Headless ERP

Was ist ein Headless-ERP?

Ein ERP, das nur als Daten- und Logikschicht dient, mit separat darauf gebauter Oberfläche. Die Website oder App ruft das ERP über die API auf, und das ERP liefert selbst keine Seiten aus. Sie erhalten eine einzige Quelle der Wahrheit für Preise, Bestände und Kunden, ohne an das Frontend des ERP-Anbieters gebunden zu sein.

Kann man Odoo headless nutzen?

Ja, und es ist eines der wenigen ERP-Systeme, bei denen das unkompliziert ist. Odoo erschliesst jede öffentliche Modellmethode einschliesslich der generischen ORM, kennt kein Limit auf Anwendungsebene und lässt sich selbst hosten, jede Decke ist also eine, die Sie selbst setzen. Bauen Sie allerdings gegen die External JSON-2 API und nicht gegen die klassischen XML-RPC- und JSON-RPC-Endpunkte, die auslaufen.

Warum nicht einfach das Website-Modul des ERP nutzen?

Weil Sie dessen Frontend erben. Wir haben neun Sites gemessen, die auf dem Odoo-Website-Modul laufen: im Median laden rund 1,5 MB JavaScript und CSS, bevor irgendetwas nutzbar ist, und odoo.com selbst liefert 1,77 MB aus. Das meiste davon ist der ERP-Web-Client, den eine Unternehmenswebsite nie benutzt. Auf einer Website, bei der Auffindbarkeit zählt, ist das ein hoher Preis für Bequemlichkeit.

Die vollständige Messung

Ist ein Headless-ERP teurer?

Anfangs meist ja, weil Sie das Frontend bauen, statt es zu bekommen. Auf längere Sicht hängt es davon ab, was Sie sonst dafür ausgegeben hätten, die Oberfläche des Anbieters zu umgehen. Die ehrliche Fassung: besteht Ihre Website aus einer Handvoll Seiten, die sich selten ändern, ist Headless überdimensioniert. Muss sie Live-Daten zeigen, Traffic tragen und ranken, zahlt es sich aus.

Was passiert, wenn das ERP ausfällt?

Ihre Website sollte weiterlaufen. Das ist eine Entwurfsanforderung und keine Nebensache: cachen Sie, was cachebar ist, degradieren Sie sauber bei allem anderen, und lassen Sie Bestellung oder Kontaktformular nie von einem synchronen Aufruf abhängen, der auslaufen kann. Hat ein Partner das vor der Unterschrift nicht angesprochen, fragen Sie warum.

Fragen Sie sich, ob Ihr ERP das trägt?

Sagen Sie uns, welches System Sie betreiben und was die Website zeigen soll. Wir sagen offen, ob es passt, auch wenn die Antwort lautet, dass Ihr aktuelles ERP das nicht tragen wird.

Ihre Situation besprechen

Odoo Gold Partner · Amsterdam · wir bauen das Frontend und behalten das ERP als Backend