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.

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 one working week 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.