Headless Odoo
Odoo runs the business: products, orders, customers, inventory, subscriptions. A frontend built in the technology your product needs runs the experience, talking to Odoo over GraphQL and REST. We have shipped this for storefronts, member portals, supplier apps and mobile.
Reviewed by Atul Makwana, CEO & Co-Founder, Heliconia Solutions · Odoo 16 Functional Certification · Odoo Partner · Updated
Businesses that run on what we built
Definition
Headless Odoo is an architecture in which Odoo is used as the backend (the system of record for products, customers, orders, inventory, accounting and business logic) while the user-facing frontend is a separate application (a Next.js website, a React Native or Flutter mobile app, a custom portal) that communicates with Odoo through APIs instead of using Odoo's built-in web interface.
The point is separation: Odoo does what it's excellent at, and the frontend is built with the tools that give the best customer, member or supplier experience. Multiple frontends (web, iOS, Android, a supplier tool) share one backend and one API.
It's also a commitment. Two codebases, an API contract to maintain, and a frontend that has to be hosted and evolved. Headless is the right architecture for some businesses and the wrong one for others, and this page is meant to help you tell which.
Architecture
The shape behind our production headless systems. Redis, search and storage appear when the product needs them, not by default.
Web frontend
Next.js / React: storefront, member portal, dashboards
Mobile apps
React Native (Expo) or Flutter: iOS and Android
Other clients
Supplier tools, partner systems, automation
API layer
GraphQL (Graphene) and REST controllers on Odoo · webhooks · Odoo session or token auth
Odoo
CRM · Sales · Inventory · Accounting · eCommerce · Subscriptions · custom modules: the business logic lives here
Services
PostgreSQL · Redis (cache, queues, presence) · Meilisearch (search) · S3 / Cloudflare R2 (media) · Socket.IO (real-time) · PayloadCMS (content)
When to use it
A brand storefront, a member community, a customer app, where the standard Odoo website would be a compromise customers notice.
Native-feeling iOS/Android apps on Odoo data: Aria Jewellers' customer app, Ramdev Kangan's supplier catalog, Freiburger Bund's member app.
Web, mobile and partner tools on one API, one set of business rules.
Static and edge rendering, aggressive caching, sub-second search with Meilisearch.
Because your team, your design system or your product roadmap already lives there.
A composable architecture where Odoo is one service among several, connected by a clear API contract.
When not to
We build both. Recommending headless where it isn't needed would cost you money and us credibility.
Most B2B and many B2C stores are well served by Odoo Website and eCommerce with targeted customization. Wild Cloud is one.
One system, one deployment, one team. Headless adds a frontend build before day one.
A catalogue, a checkout and a portal that work, not a differentiated experience.
Without a second client, the shared-API benefit largely disappears.
Two codebases need to be hosted, monitored and evolved. If nobody will own the frontend after launch, don't build one.
Getting inventory, accounting and workflows right in Odoo usually pays back faster than a custom storefront.
Traditional vs headless
Your own frontend over Odoo APIs, with Odoo still the system of record.
Odoo's own website and eCommerce, rendered by Odoo.
| What is being compared | Headless OdooYour own frontend over Odoo APIs, with Odoo still the system of record. | Traditional OdooOdoo's own website and eCommerce, rendered by Odoo. |
|---|---|---|
| Frontend | Next.js / React / React Native / Flutter | Odoo Website / backend UI, QWeb, OWL |
| Data access | GraphQL / REST API contract | Direct: same application |
| Time to first release | Longer: frontend is built separately | Shorter |
| Design freedom | Unlimited | Within Odoo's theme and view framework |
| Performance | Static/edge rendering, caching, dedicated search | Bound to Odoo rendering, fine for most cases |
| Mobile | Native apps on the same API | Responsive web, or the official Enterprise app |
| Real-time features | Dedicated services (Socket.IO, Redis) | Limited (Odoo bus) |
| Upgrades | Odoo upgrade plus API compatibility check | One system |
| Team | Odoo developers + frontend/mobile developers | Odoo developers |
| Best for | Experience-first products, mobile, multi-channel | Operations-first businesses, B2B, fast launches |
Technology stack
Only what's behind the systems on this page.
How we build it
Against the "when not to" list above. If traditional Odoo does the job, we say so.
Which Odoo models and operations the frontend needs, shaped for the screens: before either side is built.
GraphQL/REST modules, custom business logic, webhooks, authentication, indexing to search.
Next.js, React Native or Flutter against the contract, with mock data until the API is live.
Redis, Meilisearch, real-time server, media storage, only where the product needs them.
Independent deployments, monitoring on both sides, and an API versioning rule so Odoo upgrades don't break the app.
Evidence
Four production architectures: commerce, a member platform with real-time chat, a supplier app and a customer app.
eCommerce, baby care
A direct-to-consumer baby care brand selling through a Next.js storefront, with Odoo behind it for ERP, inventory, orders and customers: connected over GraphQL, with Cashfree payments, Shiprocket shipping and a distributor onboarding portal.
Healthcare association & career portal
A medical association platform where Odoo 18 Enterprise is the business backend behind a Next.js 15 web portal, React Native (Expo) iOS/Android apps, a Socket.IO messaging server and MeiliSearch: in German, English, French and Arabic.
Jewellery manufacturing
A bangle and fashion-jewellery manufacturer’s product catalog managed in Odoo and delivered to a cross-platform Flutter app over GraphQL, with media on Cloudflare R2 and production monitoring.
Jewellery retail & manufacturing
Multi-store fine jewellery retail and manufacturing on Odoo Enterprise: daily metal rates, RFID-tagged serialized stock, gold saving schemes with recurring payments, and a customer mobile app synced over GraphQL.
First-party experience
Design the API for the screens, not for the models. A GraphQL schema that mirrors Odoo tables makes the frontend slow and the backend fragile.
The API contract is the upgrade boundary. Version it, test it, and an Odoo migration stops being a frontend emergency.
Search belongs in a search engine. Odoo full-text over thousands of products or articles is where Meilisearch earned its place.
Real-time is a separate service. Freiburger Bund's chat runs on Socket.IO and Redis, authenticated by Odoo, not inside Odoo.
Headless is a commitment to two codebases. Every client we recommended it to had a reason that outlived the launch.
What clients say
Heliconia's Odoo Enterprise implementation, along with third-party system integration, has optimized our processes. Their expertise has been a game-changer.
Vladimir VukovicCEO, Mevalon ProdukteHeliconia delivered an impeccable Odoo Enterprise implementation with seamless integration. Their expertise has revolutionized our operations.
Kartson KrayChairman, TIMmunity GmbHQuestions
An architecture where Odoo is the backend (data, business logic, workflows) and a separate frontend (web or mobile, in any technology) talks to it through GraphQL or REST APIs instead of using Odoo's built-in interface.
Next.js gives static and server rendering, edge caching, a component model and SEO control that Odoo Website can't match for experience-first sites. Odoo keeps the business logic. Next.js renders it, as at LittleQ and Freiburger Bund.
Yes. Odoo exposes its models through JSON-RPC by default, and purpose-built GraphQL and REST layers make it a capable backend for web and mobile applications.
Yes. React Native and Flutter apps run on Odoo APIs in production. Aria Jewellers (customer app), Ramdev Kangan (supplier catalog), Freiburger Bund (member app), WaveContact.
When the frontend experience or a mobile app is central to the product, several frontends share one backend, or performance needs exceed Odoo's frontend. Otherwise, traditional Odoo is usually the better investment.
Initially, yes: a separate frontend is built and hosted, and the API is maintained. It pays back when the experience drives revenue, when a mobile app is required, or when multiple channels share the backend.
Yes. The API layer is custom modules on the framework, which is identical in both editions. Ramdev Kangan and LittleQ are headless systems on Odoo.
Yes with Enterprise. With a caveat on Odoo.sh. Odoo.sh can't host the extra services a headless system often needs (Redis, Meilisearch, a real-time server), so headless Enterprise systems usually run on cloud infrastructure we manage, with the frontend deployed separately.
Yes: customization is where headless starts. Business logic stays in Odoo modules. The API exposes it. Nothing about the frontend changes how Odoo itself is extended.
Yes. Odoo developers, GraphQL/API engineers, Next.js, React Native and Flutter developers and designers are one team, so the API contract is designed by people building both sides.
Related reading
Odoo
Headless Odoo approach for building scalable, modern software solutions using API-first architecture with Next.js, Flutter, and React Native across ecommerce, HRMS, and platforms.
Next step
Tell us what the frontend needs to do, whether there's a mobile app, and which Odoo version you run. We'll tell you whether headless is the right architecture, and show you how we would build it.