Headless ERP: welke systemen dit echt kunnen
Elke leverancier zegt dat zijn ERP open is. De vraag die het beslist is smaller: kan een publieke website eruit lezen, bij echt verkeer, zonder dat de leverancier bepaalt wanneer je stopt.
Wat is een headless ERP?
Een headless ERP is een ERP dat je puur als data- en logicalaag gebruikt, met de interface er los bovenop gebouwd. Je website, portaal of app praat via de API met het ERP, terwijl het ERP zelf geen pagina's toont. De aantrekkingskracht is dat je één bron van waarheid krijgt voor prijzen, voorraad en klanten zonder de eigen frontend van het ERP te erven, die meestal traag en lastig vorm te geven is. De adder is dat de meeste ERP-systemen dit technisch toestaan en praktisch niet, door wat hun API mag bereiken en hoe hard hij wordt afgeknepen.
Waarom "wij hebben een API" je bijna niets vertelt
Vraag een willekeurige ERP-leverancier of zijn systeem open is en het antwoord is ja. Er is een API, er is documentatie, misschien zelfs een developerportaal. Niets daarvan beantwoordt de vraag die je echt hebt, namelijk of je er een website voor kunt zetten en over twee jaar nog draait.
Drie dingen bepalen dat, en leveranciers zetten ze zelden naast elkaar. Het eerste is bereik: kun je bij elk object in het systeem, of alleen bij wat iemand heeft opengezet? Het tweede is het plafond: hoeveel aanroepen mag je doen voordat je wordt afgesloten, en schaalt dat plafond mee met je verkeer of met je licentie? Het derde is eigenaarschap: als het plafond te laag is, kun je het dan zelf verhogen of moet je het vragen?
Die drie scoort de matrix hieronder. Het is geen oordeel over het ERP als ERP. Exact Online is een sterk boekhoudpakket en AFAS zit niet voor niets diep in de Nederlandse HR en salaris. Dit gaat alleen over de vraag of het systeem achter een publieke frontend kan staan.
Drie routes, niet twee
Het gesprek doet meestal alsof er twee opties zijn: je ERP rendert je site, of je gaat volledig headless. In de praktijk is er een derde, en dat is degene die de meeste bedrijven kiezen: zet er een gespecialiseerd platform voor, zoals Shopify of WooCommerce voor commerce, en koppel dat aan het ERP.
-
Het ERP rendert de site
Odoo Website, of het equivalent in jouw ERP
+ Eén systeem, geen koppeling om te onderhouden, je redactie blijft werken waar ze al zat.
- Je erft de frontend. Onze meting: mediaan zo'n 1,5 MB aan JavaScript en CSS voordat er iets bruikbaar is, grotendeels de ERP web-client die je website nooit gebruikt.
-
Een gespecialiseerd platform vóór het ERP
Shopify, WooCommerce of vergelijkbaar, ERP erachter
+ Bewezen commerce, een groot plugin-ecosysteem en koppelingen die kant-en-klaar bestaan. Voor pure webshops is dit vaak echt het juiste antwoord.
- Je erft hún frontend en hún grenzen. Je content/code-verhouding is wat het platform levert, en een configurator of leadmagnet wordt een vraag over welke plugin bestaat in plaats van wat je wilt bouwen.
-
Echt headless
Je eigen frontend, ERP als datalaag
+ Volledige controle over structuur, gewicht en gereedschap. Rekentools, configurators en leadmagnets zijn iets dat je ontwerpt in plaats van iets waarnaar je zoekt.
- Je bouwt het zelf, en je bent eigenaar van de cache en het upgradepad. Overkill voor een site van een paar statische pagina's.
Het strategische probleem met de middelste route is niet technisch. Als je concurrenten allemaal op dezelfde marktleider zijn gestandaardiseerd, concurreer je op een platform dat jullie allemaal hetzelfde plafond geeft. Je kunt geen content/code-verhouding winnen die het platform niet toestaat, en je kunt niet eenvoudig die ene tool bouwen die je zou onderscheiden. Je onderscheiden op vindbaarheid terwijl je dezelfde stack draait als iedereen, is heel moeilijk.
Wat wij zelf deden, en wat het opleverde
Wij zijn Odoo Gold Partner en hebben onze eigen website bewust niet in Odoo gebouwd. Dat is een ongemakkelijk standpunt om te verdedigen, dus hier is wat er gebeurde.
De nieuwe site ging begin juni 2026 live. De vertoningen gingen van ongeveer 800 naar zo'n 2.500 per dag, ruim drie keer zoveel, en de klikken van ongeveer elf naar negentien per dag.
De eerlijke kanttekening: we hebben in diezelfde periode veel nieuwe content gepubliceerd, dus dit is niet het platform alleen. Content en platform zijn hier niet te scheiden. Wat we wel kunnen zeggen: dezelfde content had op de ERP-websitemodule nooit deze snelheid en structuur gekregen, en de tools die we konden bouwen omdat we de frontend zelf bezitten zijn een deel van waarom het werkt. Het is bovendien nog vroeg: Google is nog niet klaar met herindexeren, dus het beeld is niet definitief.
Search Console, daggemiddelde
- Vertoningen ~800 ~2.500
- Klikken ~11 ~19
De drie toetsen
Dit scoort de matrix, elk op een schaal van nul tot twee.
-
Bereik
Kun je elk object lezen en schrijven, of alleen wat een beheerder heeft opengezet? Een ERP waarin iemand vooraf elke weergave moet definiëren is prima voor rapportage en vervelend voor een website, want elke nieuwe pagina begint met een verzoek aan iemand anders.
-
Plafond
Hoeveel aanroepen voordat je wordt afgeknepen, en groeit dat plafond mee met verkeer of met wat je betaalt? Een harde dagelijkse limiet is het verschil tussen een site die meeschaalt en een site die op een drukke dag stopt.
-
Eigenaarschap
Als het plafond te laag is, kun je het dan zelf verhogen? Op een systeem dat je zelf host is de limiet er een die jij zet. Op een cloud-only systeem is de limiet een commerciële beslissing van iemand anders.
Welke ERP-systemen echt headless kunnen
Gescoord op de drie toetsen hierboven, gesorteerd op totaal. Wij bouwen op Odoo, dus lees de bovenste regel met dat in het achterhoofd; de onderliggende cijfers zijn door de leveranciers zelf gedocumenteerd en staan onderaan verantwoord.
| ERP | API | Bereik | Plafond | Eigenaarschap | Oordeel |
|---|---|---|---|---|---|
| Odoo Volledige toegang tot elke publieke modelmethode inclusief de generieke ORM. Geen limiet op applicatieniveau: die zet je zelf op de proxy, want een onbeschermde instantie gaat om. Open source, dus je kunt zelf hosten. | XML-RPC, JSON-RPC, JSON-2 | ●● | ●● | ●● | Geschikt |
| SAP Business One De Service Layer ontsluit het objectmodel breed. Geen gepubliceerde limiet per minuut; batchbewerkingen zijn beperkt boven ongeveer 300 records. Kan op eigen infrastructuur draaien. | Service Layer (OData) | ●● | ●○ | ●● | Werkbaar, met kanttekeningen |
| Microsoft Dynamics 365 BC 6.000 verzoeken per vijf minuten per gebruiker en vijf gelijktijdige verbindingen, wat ruim is. Alleen cloud, dus het plafond is niet van jou. | OData / API pages | ●● | ●○ | ○○ | Niet echt |
| NetSuite Breed bereik, maar gelijktijdigheid wordt bepaald door je service tier en het aantal SuiteCloud Plus-licenties. Het plafond is een commerciële variabele. | SuiteTalk SOAP/REST, RESTlets | ●● | ●○ | ○○ | Niet echt |
| Exact Online 60 aanroepen per minuut en 5.000 per dag, per administratie. Die dagelijkse limiet is de knellende: je bereikt hem eerder dan je verkeer. | REST | ●○ | ○○ | ○○ | Niet echt |
| AFAS Data is alleen bereikbaar via GetConnectors en UpdateConnectors die een beheerder eerst in AFAS definieert. Uitstekend voor gecontroleerde koppelingen, onhandig als een website een veld nodig heeft dat nog niemand heeft opengezet. | GetConnector / UpdateConnector | ○○ | ●○ | ○○ | Niet echt |
Twee is goed, één is werkbaar, nul is een blokkade.
Limieten overgenomen uit leveranciersdocumentatie, gecontroleerd juli 2026: Odoo external API reference, Exact Online API-limieten, Microsoft Learn over Business Central API-limieten, Oracle NetSuite concurrency governance, AFAS-connectordocumentatie en SAP Business One Service Layer. Limieten veranderen; controleer ze opnieuw voordat je er iets omheen ontwerpt.
Eén ding over Odoo dat je moet weten voordat je bouwt
De klassieke XML-RPC- en JSON-RPC-endpoints verdwijnen in Odoo 22 (najaar 2028) en Odoo Online 21.1 (winter 2027), vervangen door de External JSON-2 API. Wat je vandaag bouwt, moet op die nieuwe API mikken. We noemen het omdat dit precies het soort detail is dat makkelijk uit een verkoopgesprek blijft en duur is om achteraf te ontdekken.
Wat headless je kost, eerlijk gezegd
Headless is geen gratis architectuur. Je neemt werk over dat de leverancier eerst voor je deed, en dat komt op drie plekken terug.
Je bent nu eigenaar van de frontend. Niemand stuurt je bij de volgende release een template. Elke pagina, elk formulier en elke toestand die je ERP kan opleveren, moet ergens bestaan die jij hebt gebouwd. Voor een bedrijfssite is dat een paar weken; voor een volledig klantportaal is het een project.
Je bent nu eigenaar van de cache. Een ERP is niet gebouwd om duizend anonieme verzoeken per minuut te beantwoorden, en zelfs als er geen gepubliceerde limiet is moet je je gedragen alsof die er wel is. Prijzen en voorraad worden gecachet, cache-invalidatie wordt iets waar je over na moet denken, en "waarom staat de prijs van gisteren op de site" wordt een vraag die je moet kunnen beantwoorden.
En je bent nu eigenaar van het upgradepad. De API waar je tegenaan bouwt gaat veranderen. Odoo heeft al aangekondigd dat de klassieke XML-RPC- en JSON-RPC-endpoints verdwijnen, en dat is precies het soort ding dat alleen pijn doet als je niet oplette. Het is te doen, maar het is echt werk, en een partner die je vertelt dat headless alleen maar voordelen heeft, heeft er nog niet lang genoeg een gedraaid.
Veelgestelde vragen over headless ERP
Wat is een headless ERP?
Een ERP dat je alleen als data- en logicalaag gebruikt, met de interface er los bovenop gebouwd. De website of app roept het ERP aan via de API en het ERP toont zelf geen pagina's. Je krijgt één bron van waarheid voor prijzen, voorraad en klanten zonder vast te zitten aan de eigen frontend van de ERP-leverancier.
Kun je Odoo headless gebruiken?
Ja, en het is een van de weinige ERP-systemen waar dit rechttoe rechtaan is. Odoo ontsluit elke publieke modelmethode inclusief de generieke ORM, kent geen limiet op applicatieniveau, en kan zelf gehost worden, dus elk plafond is er een dat je zelf zet. Bouw wel tegen de External JSON-2 API en niet tegen de klassieke XML-RPC- en JSON-RPC-endpoints, die worden uitgefaseerd.
Waarom niet gewoon de website-module van het ERP gebruiken?
Omdat je de frontend ervan erft. We hebben negen sites gemeten die op de Odoo-websitemodule draaien: mediaan zo'n 1,5 MB aan JavaScript en CSS laadt voordat er iets bruikbaar is, en odoo.com zelf levert 1,77 MB. Het grootste deel daarvan is de ERP web-client, die een bedrijfssite nooit gebruikt. Op een site waar vindbaarheid telt is dat een hoge prijs voor gemak.
Is een headless ERP duurder?
Vooraf meestal wel, omdat je de frontend bouwt in plaats van hem te krijgen. Over langere tijd hangt het af van wat je anders kwijt was geweest aan het omzeilen van de interface van de leverancier. De eerlijke versie: als je site een handvol pagina's is die zelden verandert, is headless overkill. Moet je site live data tonen, verkeer dragen en ranken, dan verdient het zich terug.
Wat gebeurt er als het ERP eruit ligt?
Je site hoort door te werken. Dat is een ontwerpeis en geen bijzaak: cache wat te cachen valt, degradeer netjes op wat dat niet kan, en laat een bestelling of contactformulier nooit afhangen van een synchrone aanroep die kan aflopen. Heeft een partner dit niet aangekaart voordat je tekende, vraag dan waarom.
Benieuwd of jouw ERP dit aankan?
Vertel ons welk systeem je draait en wat de site moet tonen. We zeggen eerlijk of het past, ook als het antwoord is dat je huidige ERP dit niet gaat dragen.
Odoo Gold Partner · Amsterdam · wij bouwen de frontend en houden het ERP als backend