Headless ERP: which systems can actually do it
Every vendor says their ERP is open. The question that decides it is narrower: can a public website read from it, at real traffic, without the vendor deciding when you stop.
What is a headless ERP?
A headless ERP is an ERP used purely as a data and logic layer, with the interface built separately on top of it. Your website, portal or app talks to the ERP over its API, while the ERP itself renders no pages. The appeal is that you get one source of truth for prices, stock and customers without inheriting the ERP's own front end, which is usually slow and hard to shape. The catch is that most ERPs technically allow it and practically do not, because of what their API is allowed to reach and how hard it is throttled.
Why "we have an API" tells you almost nothing
Ask any ERP vendor whether their system is open and the answer is yes. There is an API, there is documentation, there may even be a developer portal. None of that answers the question you actually have, which is whether you can put a website in front of it and still be running in two years.
Three things decide that, and vendors rarely put them next to each other. The first is reach: can you get at every object in the system, or only at the ones someone decided to expose? The second is the ceiling: how many calls may you make before you are cut off, and does that ceiling scale with your traffic or with your licence fee. The third is ownership: if the ceiling is too low, can you raise it yourself or do you have to ask.
Those three are what the matrix below scores. They are not a judgement of the ERP as an ERP. Exact Online is a strong accounting package and AFAS is deeply embedded in Dutch HR and payroll for good reasons. This is only about whether the system can sit behind a public front end.
Three routes, not two
Most of the discussion pretends there are two options: let the ERP render your site, or go fully headless. In practice there is a third, and it is the one most companies pick: put a specialised platform in front, such as Shopify or WooCommerce for commerce, and connect it to the ERP.
-
The ERP renders the site
Odoo Website, or the equivalent in your ERP
+ One system, no integration to maintain, editors stay where they already work.
- You inherit its front end. Our measurement: a median of roughly 1.5 MB of JavaScript and CSS before anything is usable, most of it the ERP web client your website never uses.
-
A specialised platform in front of the ERP
Shopify, WooCommerce or similar, ERP behind it
+ Proven commerce, a large plugin ecosystem and connectors that exist off the shelf. For pure webshops this is often genuinely the right answer.
- You inherit their front end and their limits. Your content-to-code ratio is whatever the platform ships, and a configurator or lead magnet becomes a question of which plugin exists rather than what you want to build.
-
Truly headless
Your own front end, ERP as data layer
+ Full control over structure, weight and tooling. Calculators, configurators and lead magnets are something you design rather than something you shop for.
- You build it, and you own the caching and the upgrade path. Over-engineering for a site of a few static pages.
The strategic problem with the middle route is not technical. If your competitors have all standardised on the same market leader, you are competing on a platform that gives every one of you the same ceiling. You cannot win a content-to-code ratio the platform does not allow, and you cannot easily build the one tool that would set you apart. Differentiating on findability while running the same stack as everyone else is very hard.
What we did ourselves, and what it did
We are an Odoo Gold Partner and we deliberately did not build our own website in Odoo. That is an awkward position to defend, so here is what happened.
The new site went live at the start of June 2026. Impressions went from around 800 to roughly 2,500 a day, more than three times, and clicks from about eleven to nineteen a day.
The honest caveat: we published a great deal of new content in the same period, so this is not the platform alone. Content and platform are not separable here. What we can say is that the same content would never have had this speed or structure on the ERP website module, and that the tools we could build because we own the front end are part of why it works. It is also still early: Google has not finished reindexing, so the picture is not final.
Search Console, daily average
- Impressions ~800 ~2,500
- Clicks ~11 ~19
The three tests
These are what the matrix scores, each on a scale of zero to two.
-
Reach
Can you read and write every object, or only the ones an administrator has exposed? An ERP where a person has to define each view up front is fine for reporting and painful for a website, because every new page starts with a request to someone else.
-
Ceiling
How many calls before you are throttled, and does that ceiling grow with traffic or with what you pay? A hard daily cap is the difference between a website that scales and one that stops on a busy day.
-
Ownership
If the ceiling is too low, can you raise it yourself? On a system you host, the limit is one you set. On a cloud-only system, the limit is a commercial decision made by someone else.
Which ERPs can actually run headless
Scored on the three tests above. Sorted by total, highest first. We build on Odoo, so read the top row with that in mind; the underlying figures are documented by each vendor and linked below.
| ERP | API | Reach | Ceiling | Ownership | Verdict |
|---|---|---|---|---|---|
| Odoo Full access to every public model method including the generic ORM. No rate limit at application level: you set your own at the proxy, because an unprotected instance will fall over. Open source, so you can host it yourself. | XML-RPC, JSON-RPC, JSON-2 | ●● | ●● | ●● | Suitable |
| SAP Business One Service Layer exposes the object model broadly. No per-minute limit published; batch operations are restricted above roughly 300 records. Can run on your own infrastructure. | Service Layer (OData) | ●● | ●○ | ●● | Workable, with caveats |
| Microsoft Dynamics 365 BC 6,000 requests per five minutes per user and five concurrent connections, which is generous. Cloud only, so the ceiling is not yours to raise. | OData / API pages | ●● | ●○ | ○○ | Not really |
| NetSuite Broad access, but concurrency is governed by your service tier and the number of SuiteCloud Plus licences. The ceiling is a commercial variable. | SuiteTalk SOAP/REST, RESTlets | ●● | ●○ | ○○ | Not really |
| Exact Online 60 calls per minute and 5,000 per day, per administration. That daily cap is the binding constraint for a public site: it is reached before the traffic is. | REST | ●○ | ○○ | ○○ | Not really |
| AFAS Data is reachable only through GetConnectors and UpdateConnectors that an administrator defines in AFAS first. Excellent for controlled integrations, awkward when a website needs a field nobody exposed yet. | GetConnector / UpdateConnector | ○○ | ●○ | ○○ | Not really |
Two is good, one is workable, zero is a blocker.
Limits taken from vendor documentation, checked July 2026: Odoo external API reference, Exact Online API limits, Microsoft Learn on Business Central API limits, Oracle NetSuite concurrency governance, AFAS connector documentation and SAP Business One Service Layer guidance. Limits change; check them again before you design around one.
One thing about Odoo you should know before you build
The classic XML-RPC and JSON-RPC endpoints are scheduled for removal in Odoo 22 (autumn 2028) and Odoo Online 21.1 (winter 2027), replaced by the External JSON-2 API. Anything built today should target the new API. We mention this because it is exactly the kind of detail that is easy to leave out of a sales conversation and expensive to discover afterwards.
What headless costs you, honestly
Headless is not free architecture. You are taking on work the vendor used to do for you, and that shows up in three places.
You now own the front end. Nobody ships you a template with the next release. Every page, every form and every state your ERP can produce has to exist somewhere you built. For a company site that is a few weeks; for a full customer portal it is a project.
You now own the caching story. An ERP is not built to answer a thousand anonymous requests a minute, and even when there is no published rate limit you should behave as if there is one. Prices and stock get cached, cache invalidation becomes something you have to think about, and "why does the site show yesterday's price" becomes a question you have to be able to answer.
And you now own the upgrade path. The API you build against will change. Odoo has already announced that the classic XML-RPC and JSON-RPC endpoints go away, which is exactly the kind of thing that only hurts if you were not watching. That is manageable, but it is real work, and any partner who tells you headless is purely upside has not run one for long enough.
Frequently asked questions about headless ERP
What is a headless ERP?
An ERP used only as a data and logic layer, with the interface built separately on top of it. The website or app calls the ERP over its API and the ERP renders no pages itself. You get one source of truth for prices, stock and customers without being tied to the ERP vendor's own front end.
Can Odoo be used headless?
Yes, and it is one of the few ERPs where this is straightforward. Odoo exposes every public model method including the generic ORM, applies no rate limit at application level, and can be self-hosted, so any ceiling is one you set yourself. Build against the External JSON-2 API rather than the classic XML-RPC and JSON-RPC endpoints, which are being retired.
Why not just use the ERP's own website module?
Because you inherit its front end. We measured nine sites running on Odoo's website module: a median of roughly 1.5 MB of JavaScript and CSS loads before anything is usable, and odoo.com itself ships 1.77 MB. Most of that is the ERP web client, which a company website never uses. On a site where findability matters, that is a high price for convenience.
Is a headless ERP more expensive?
Up front, usually yes, because you build the front end instead of receiving it. Over time it depends on what you would otherwise have spent working around the vendor's interface. The honest version: if your site is a handful of pages that rarely change, headless is over-engineering. If your site has to show live data, carry traffic and rank, it pays back.
What happens if the ERP is down?
Your site should keep working. That is a design requirement, not an afterthought: cache what can be cached, degrade gracefully on what cannot, and never let a checkout or a contact form depend on a synchronous call that might time out. If a partner has not raised this before you sign, ask why.
Wondering whether your ERP can carry this?
Tell us which system you run and what the site has to show. We will say plainly whether it is a fit, including when the answer is that your current ERP will not carry it.
Odoo Gold Partner · Amsterdam · we build the front end and keep the ERP as backend