A build-to-order Odoo module that exposes your eCommerce catalog, cart, checkout, orders and customer accounts as a clean REST and GraphQL API. ECOSIRE builds, installs and supports it so your headless storefront or mobile app can treat Odoo as the single source of truth. Built to order by ECOSIRE for Odoo 17, 18, 19 — indicative price from $799.00 USD; request a quote for a scoped proposal.

A build-to-order Odoo module that exposes your eCommerce catalog, cart, checkout, orders and customer accounts as a clean REST and GraphQL API. ECOSIRE builds, installs and supports it so your headless storefront or mobile app can treat Odoo as the single source of truth.
No payment now. This sends a quote request to our team — we'll follow up by email with pricing and next steps.
Odoo's website_sale gives you a serviceable server-rendered shop, but the moment you want a Next.js/Nuxt storefront, a React Native app, or a PWA on top of it, the road runs out. The stock JSON-RPC/XML-RPC API is generic ORM plumbing — it speaks read/search_read over raw model fields, not a stable, versioned commerce contract. There is no first-class cart-session endpoint, no clean checkout state machine, no CORS story for a browser client, no token model separate from a logged-in Odoo web session, and no webhooks for order or stock events. Teams end up scraping controllers, over-fetching whole records, and re-implementing pricelist and tax logic on the frontend — which drifts from Odoo the day a rule changes.
REST endpoints (`http.Controller`, `type='json'`) for catalog, product detail, cart, checkout, orders and customer account, returning lean serialized DTOs rather than raw `search_read` records
GraphQL endpoint with a typed schema so storefront clients select exactly the fields they render and avoid over-fetching across product/variant/price relations
Bearer-token authentication via a dedicated API-client model, decoupled from the Odoo web session, with tokens protected by `ir.model.access.csv` and record rules
Per-token rate limiting with configurable windows and quotas, returning standard `429` plus `Retry-After` headers
Allow-listed CORS origin table managed from an OWL/XML settings view, so browser storefronts get correct preflight handling without opening the instance to `*`
Catalog reads resolve real Odoo data — `product.template`/`product.product`, variant attribute lines, `product.pricelist` prices and `stock.quant` availability, including `@api.depends` computed fields
We build a dedicated storefront API module that turns your Odoo instance into a proper headless commerce backend. It ships as a standard addon (__manifest__.py declaring web, sale, website_sale and stock dependencies) exposing two coordinated surfaces: a resource-oriented REST layer via http.Controller routes (type='json', token-scoped auth) and a GraphQL endpoint for clients that want to select exactly the fields they render in one round-trip. Catalog reads resolve real Odoo data — product.template/product.product, variant attribute lines, product.pricelist prices, on-hand quantities from stock.quant, and any @api.depends computed fields — so pricing and availability are always what Odoo itself would compute, never a frontend guess. Responses are shaped by explicit serializer methods, so you return lean DTOs instead of leaking every column.
Technically, the module adds a token model (a new models.Model for API clients and issued tokens, protected by ir.model.access.csv and record rules so a token only ever sees its own organization's data), a request-authentication layer that validates the bearer token on every call, configurable per-token rate limiting, and an allow-listed CORS origin table you manage from a settings view (XML/OWL). Cart and checkout map onto a sale.order in draft/sent state: add-line, update-qty, apply-coupon, set-address and confirm are individual endpoints that mutate the order through Odoo's own _amount_all / tax engine rather than parallel math. Multi-currency and multi-locale are first-class — responses honor the pricelist currency and the res.lang you pass, and translatable fields resolve through Odoo's translation layer. Outbound webhooks fire from automated actions / create/write overrides on order, inventory and price events, signed with an HMAC secret so your storefront (or a downstream service) can react to order.confirmed, stock.changed or price.updated without polling.
Because this is build-to-order, nothing is a black box you download blind. We start from your actual catalog structure, pricelist rules, tax setup and the exact edition you run (Community vs Enterprise — for example, Enterprise-only fields or delivery/account integrations are wired only if you have them), then scope the endpoint set your storefront actually needs. We develop against your data model, build on Odoo 17.0, 18.0 or 19.0 to match your instance, and validate on a staging copy before anything touches production.
Typical delivery is 2–4 weeks from confirmed scope, depending on how many endpoints, webhook events and custom fields you need. You receive the full installable source, technical and API documentation, a training session for your frontend and ops teams, and a post-go-live support window. It is a real Odoo module you own — not a hosted middleman between your storefront and your ERP.
Building a Next.js, Nuxt or Astro storefront and needs a stable, versioned commerce contract — cart, checkout, pricing and stock — instead of hand-rolling calls against raw Odoo ORM records that break on every model change.
Shipping a React Native or Flutter shopping app that must authenticate customers, list the live catalog, run checkout and read order history through clean token-authenticated endpoints, with webhooks to keep the app in sync.
Runs Odoo as the ERP of record and wants a composable/headless architecture where Odoo stays the single source of truth for catalog, pricing and orders, without a third-party commerce middleman owning the data.
Delivering a headless build for a client on Odoo and needs a supported, documented API layer they can build the storefront and any downstream services against, with a git handover and defined support window.
Buy the license on ecosire.com and download the Headless E-Commerce / Storefront API Layer module ZIP from your account dashboard.
Extract the ZIP into your Odoo custom addons folder on the server (or upload via Apps > Install from file on Odoo.sh / runbot).
Activate Developer Mode, open Apps, click Update Apps List, search for Headless E-Commerce / Storefront API Layer, and press Install.
Open the new menu, paste your ECOSIRE license key, connect any external credentials (Shopify, Amazon, Stripe, etc.), and save.
Run the built-in connection test, sync your first 10 records, and schedule the recurring cron. Contact support if anything fails.
| Criterion | ECOSIRE | Custom Build | Competitor | Odoo Native |
|---|---|---|---|---|
| API contract | Versioned REST + GraphQL commerce contract with lean DTOs | Whatever you hand-build; often unversioned and ad hoc | Generic CRUD over models, not commerce-shaped | |
| Cart & checkout | Dedicated endpoints mapped onto `sale.order` via Odoo's tax engine | You wire the order state machine yourself | Rarely covered; read-focused connectors | |
| Auth model | Token model separate from web session, per-token scope | DIY; easy to leak session or over-permission | Often a shared API key with broad access | |
| CORS & rate limiting | Allow-listed origins + per-token limits, admin-managed | Must be added and maintained by hand | Usually absent or fixed | |
| Webhooks | Signed events for order/stock/price, with retry | Built per-event if you have time | Limited or none; polling expected | |
| Multi-currency & locale | Pricelist currency + `res.lang` resolved server-side | Frontend conversion, drifts from Odoo | Partial, often single-currency | |
| Fit to your data | Built against your catalog, pricelists and edition | Fully bespoke but you own all the effort | One-size-fits-all, config-limited | |
| Ownership & support | Full source, git handover, defined support window | You own and support everything | Vendor-locked, support varies by plan |
This is a build-to-order module, not an instant download. Typical delivery is 2–4 weeks from confirmed scope, depending on how many endpoints, webhook events, custom fields and locales you need. After a short scoping call we give you a fixed scope and timeline, build against your actual catalog and pricelist rules, and validate on staging before production.
Every engagement includes a post-go-live support window for defect fixes and configuration changes. Because you receive the full source and a git repository, your team can extend it freely, and we offer ongoing support or a version-upgrade engagement (for example moving the module from Odoo 18.0 to 19.0) as a follow-on.
Both are available and we scope to what your storefront needs. REST endpoints (`http.Controller`, `type='json'`) suit straightforward resource access and webhooks; the GraphQL endpoint suits clients that want field-level selection and fewer round-trips. Many teams use REST for cart/checkout mutations and GraphQL for catalog reads.
Both. The core storefront API is built on standard `sale`, `website_sale` and `stock` models present in Community and Enterprise. Enterprise-only integrations (such as certain `delivery`, subscription or advanced accounting features) are wired only if you run Enterprise and ask for them, so you are never billed for surfaces you cannot use.
Access uses a dedicated API-client/token model separate from the Odoo web session, with bearer-token validation on every request. Data is protected by `ir.model.access.csv` and record rules so a token only reads its own organization's records, requests are rate-limited per token, and CORS is restricted to an allow-listed set of origins you control. Webhooks are HMAC-signed so receivers can verify authenticity.
Yes — that is the point. Prices resolve through `product.pricelist`, taxes and totals through Odoo's own `_amount_all`/tax engine, and availability from `stock.quant`. The API never re-implements commerce math on the frontend, so when a pricelist or tax rule changes in Odoo, the storefront reflects it immediately.
Yes. Signed outbound webhooks fire on `order.confirmed`, order status changes, `stock.changed` and `price.updated` events from automated actions and model overrides, so your storefront or a downstream cache updates without polling. Which events fire, and their payloads, are part of the scope we agree up front.
A build-to-order Odoo module that exposes your eCommerce catalog, cart, checkout, orders and customer accounts as a clean REST and GraphQL API. ECOSIRE builds, installs and supports it so your headless storefront or mobile app can treat Odoo as the single source of truth.