Customer portals: Odoo's portal or a custom build?

If your customers mainly need to see their quotations, orders, invoices, tickets or project tasks, and to sign, pay or comment on them, start with Odoo's own portal: it already does this, it is Community (LGPL) software, and it follows your access rules. Extend it when you need extra fields, your own branding or one or two new document types. Build a separate frontend on Odoo's API only when the experience itself is the product, such as a mobile-first app, a complex configurator or heavy public traffic.

What the Odoo 19 portal gives you out of the box

The portal module ("Customer Portal") sits under every other app. It gives each portal user a home page at /my with a count for each document type, an account page for contact details (/my/account), saved addresses, and a security page (/my/security) where they change their password or close their account. Install auth_totp or auth_passkey and their small portal bridges install themselves, so customers can turn on two-factor authentication or passkeys from that same page.

Each business app then adds its own section. In the Odoo 19 source, sixteen modules extend the portal home page. The ones businesses use most:

A few pieces sit under all of these. Any record built on the portal.mixin model gets a secure share link with an access token, so a customer can open a quotation from an email without logging in. The chatter on each record shows in the portal too, so customers and your team talk on the document rather than in a separate email thread. And the portal is just another view of your data: a portal user sees only what the record rules allow, and you don't have to rebuild those rules somewhere else.

How to switch it on sensibly

1. Choose how customers get accounts. In Settings, the Customer Account option has two values: On invitation (B2B, you invite each contact) and Free sign up (anyone can register). Most B2B businesses should start with invitations.
2. Invite contacts. Select contacts and use the Grant portal access action. The wizard shows each contact's email status and whether they have already logged in.
3. Set sales confirmation rules. In Sales settings, Online Signature is on by default. Online Payment can require full or partial prepayment before an order confirms. Both can be changed per order or per quotation template.
4. Connect a payment provider so that "Pay now" on invoices and quotations actually works. In India that usually means a provider that handles UPI and cards in INR.
5. Test as a portal user. Create a test contact, log in as them, and check what they can and cannot see before anyone real is invited.

When to extend the portal instead of replacing it

The portal is QWeb templates on server-rendered pages, served from Odoo's own controllers. That makes it cheap to extend with a normal Odoo module:

• Branding and layout. Inherit the portal templates, or use the Website app if you have it, so the portal looks like the rest of your site.
• Extra fields. Add a delivery window, a customer PO number or a GST number to the order or account pages.
• A new document type. Warranty claims, sample requests, service contracts: a model that inherits portal.mixin, a controller for the list and detail pages, and a card on the home page.

Customisations like these move forward with Odoo upgrades much more easily than a separate application does, because they use the same framework as everything else. They also keep one security model. If the portal needs are about showing and approving Odoo documents, extending is almost always the right call.

When a separate frontend on Odoo's API makes sense

Some portals are really products. A separate frontend, written in React or Next.js, a mobile framework or similar and talking to Odoo over its API, earns its extra cost when:

• the experience is the selling point: a product configurator, a self-service onboarding flow, a dealer app your field reps use all day;
• customers need a mobile app or offline use, which server-rendered portal pages won't give you;
• the portal combines Odoo with other systems (a logistics tracker, a separate billing platform) and Odoo is only one source;
• you expect heavy public traffic that you would rather not put on your ERP server;
• a separate team needs to release on its own schedule.

Odoo 19 gives you a better API for this than earlier versions did. The new JSON-2 endpoint takes POST /json/2/<model>/<method> calls authenticated with an API key as a bearer token. The older /xmlrpc and /jsonrpc endpoints still work but are deprecated in Odoo 19, and Odoo's documentation schedules their removal for Odoo 22 (fall 2028). Anything new should use JSON-2.

POST /json/2/sale.order/search_read
Authorization: bearer <api-key>
Content-Type: application/json

{"domain": [["partner_id", "=", 42]], "fields": ["name", "state", "amount_total"]}

Build it with a backend-for-frontend: a small server you control sits between the browser and Odoo, holds the API key, checks who the logged-in customer is and asks Odoo only for that customer's records. Never put an Odoo API key in browser or mobile app code. Odoo also has a Customer API Keys setting (visible in developer mode) that lets portal users create their own keys, which can suit B2B customers who want to connect their systems directly. Those keys are limited by the same record rules as the portal user.

A custom portal does not remove the Odoo work. It adds a second application that has to agree with Odoo about who can see what.

Where teams go wrong with custom portals

• One all-powerful integration user. Your custom backend then carries every access rule itself, and one missed filter exposes another customer's invoices. Restrict what the integration user can do, and filter by customer in one place in the code.
• Copying data instead of reading it. A nightly copy of orders into a separate database makes the portal disagree with Odoo by the afternoon. Read live for documents; cache only catalogue data.
• Rebuilding payments. Odoo already records payment transactions against invoices and orders. If the custom frontend takes payments, send them to Odoo's records, or your accountants will reconcile two systems.
• Forgetting upgrades. Model and field names change between major versions. Keep the API calls in one layer so an Odoo upgrade is one piece of work, not a search through the whole frontend.

Our default

We start with the standard portal, configured properly, and extend it with a module for the few things it lacks. We propose a separate frontend when the brief includes mobile, offline, a configurator or several backends. Often the answer is both: the standard portal for invoices and documents, and a focused app for the one workflow that needs it. If you are weighing this up, our notes on choosing a web application stack cover the frontend side, and our web application work or a short call can cover the rest.