How to build a customer portal connected to your ERP or CRM

To build a customer portal connected to your ERP or CRM, put a small back-end service between the portal and the business system. Customers log in to the portal through a dedicated authentication provider, the back end looks up which ERP or CRM account they belong to, and it fetches only that customer's records through the system's API using a server-side key that never reaches the browser. Before building anything, check whether your ERP's built-in portal already covers what customers need.

This guide walks through that decision, the architecture we use, the API details for Odoo and GoHighLevel, and the security points that matter most.

Do you need a custom portal, or is the built-in one enough?

Many ERPs and CRMs ship with a basic portal. Odoo is a good example. Its user portal module is available by default, and according to Odoo's documentation customers and vendors can use it to follow, view and pay orders, download or pay invoices (including partial payments and down payments), manage payment methods and subscriptions, and update their addresses. Odoo's Enterprise subscription agreement also states that portal users are not counted as paying users, so giving every customer a login does not raise your licence bill.

The built-in portal is often the right first step. It stops being enough when:

• Customers need to do things, not just view them. Odoo's documentation notes that portal users have read/view access only.
• You want to combine data from more than one system, for example orders from the ERP and support history from the CRM.
• The portal has to follow your own branding, layout or language closely, or work well on a phone in the field.
• You need custom workflows such as reordering from a contract price list, booking service visits, uploading compliance documents or approving quotes with internal rules.
• Different people at the same customer company need different permissions (buyer, accounts payable, site manager).

If none of these apply, configure the built-in portal and stop there. If several apply, a custom portal is worth scoping. Our guide to custom web app vs off-the-shelf software covers that decision in more depth.

How should a customer portal connect to an ERP?

The pattern that holds up best has three layers.

1. The front end. A React or Next.js app that customers use in the browser. It knows nothing about the ERP and holds no ERP credentials.
2. The portal back end. A Node.js and TypeScript service (or Next.js server routes) that authenticates the customer, maps them to an ERP or CRM record, calls the business system's API and returns only the fields the screen needs.
3. The system of record. Odoo, GoHighLevel or another ERP or CRM stays the source of truth for orders, invoices, contacts and stock.

A PostgreSQL database in the portal back end stores portal-only data: user accounts, the mapping between portal users and ERP partner or contact IDs, preferences, audit logs and cached data where it helps. It should not become a second copy of your ERP.

Live calls or synced data?

There are two ways to get data into the portal, and most projects use both.

Approach	How it works	Good for	Watch out for
Live API calls	The back end calls the ERP each time a page loads	Order status, invoice balances, anything that must be current	ERP response time and API limits; add short caching
Scheduled sync	A job copies selected records into the portal database on a timer	Product catalogs, price lists, large document lists, search	Data can be minutes old; needs conflict rules
Event-driven (webhooks)	The ERP or CRM notifies the portal when a record changes	Notifications, status changes, near-real-time updates	Retries and missed events need handling

Writes (a new order, a booking, an uploaded document) should go to the ERP or CRM first. The portal only shows success once the system of record has accepted the change.

Connecting to Odoo: what to know about the API

Odoo exposes its models (contacts, sales orders, invoices, products and so on) over HTTP. A few details shape any Odoo portal project in 2026:

• Odoo 19 introduced the External JSON-2 API. Requests are JSON posts to /json/2/<model>/<method>, authenticated with a bearer API key.
• Odoo's documentation marks the older XML-RPC and JSON-RPC endpoints (/xmlrpc, /xmlrpc/2 and /jsonrpc) as deprecated, with removal scheduled for Odoo 22 (fall 2028) and Online 21.1 (winter 2027). New integrations should use JSON-2 where the database version supports it.
• On Odoo Online, external API access is only available on the Custom pricing plan, not on One App Free or Standard. Odoo.sh and self-hosted databases do not have this plan restriction, according to third-party integration guides.
• API keys are created per user under Account Security. Odoo's documentation says a key is equivalent to that user's password for API use, so create a dedicated integration user with only the access rights the portal needs.

Every Odoo database has its own models and custom fields, and the JSON-2 documentation points to each database's /doc page to see what is available. If you are mid-upgrade, plan the integration against the version you will run after go-live. Our team handles both sides of this as part of Odoo implementation and customization.

Connecting to a CRM such as GoHighLevel

CRM-connected portals tend to focus on bookings, onboarding forms, documents and communication history. GoHighLevel's API v2 supports two authentication methods: OAuth 2.0 for marketplace apps, and Private Integration Tokens for internal or single-account integrations. HighLevel's help center says Private Integrations let you restrict the scopes a developer can access, and that the old v1 API keys reached end of support on December 31, 2025. For a portal tied to one sub-account, a Private Integration Token with the minimum scopes, stored only on the server, is the usual choice.

The same rules apply as with an ERP: the CRM is the source of truth, the portal back end holds the token, and each customer only ever sees their own contact's data.

How do customers log in, and how do you keep data separate?

Authentication and data separation are where portal projects go wrong, so we treat them as first-class requirements.

Authentication options

• Email and password with multi-factor authentication. Familiar, works everywhere.
• Magic links or one-time codes by email. Fewer support tickets for forgotten passwords, good for customers who log in rarely.
• Passkeys. Faster and phishing-resistant, now supported by the major browsers and several authentication providers.
• Single sign-on (SAML or OIDC) for large B2B customers who want their staff to log in with company accounts.

We use a proven authentication provider rather than writing login code. Managed options such as Clerk (whose free Hobby plan covers up to 50,000 monthly retained users per app) or Supabase Auth (included in Supabase's plans) handle password storage, MFA and session security, and keep running costs low for most SMEs.

Data separation rules

• Map each portal user to one or more ERP partner or CRM contact IDs on the server. Never trust an ID sent from the browser.
• Filter every API query by that mapping, and test that a user cannot open another customer's invoice by changing a number in the URL.
• Give the integration user in the ERP the narrowest access rights possible.
• Log who viewed and changed what, so you can answer customer and auditor questions.
• Keep API keys and tokens in server-side secrets, rotate them, and revoke them when staff or vendors change.

What does building a customer portal involve, step by step?

1. List the five to ten things customers ask your team for most often by email or phone. Those are the first portal features.
2. Check the built-in portal of your ERP or CRM against that list.
3. Confirm API access on your current plan and version, and create a dedicated integration user.
4. Clean the customer records the portal will rely on: duplicates, missing emails, wrong company links.
5. Build the first phase with live data in a staging environment, and review it weekly with the people who answer customer calls today.
6. Pilot with a small group of friendly customers, fix what they find, then roll out.

At Dymaxel, a customer portal or booking system typically starts from $15,000 and takes 6 to 10 weeks, depending on integrations and data quality. Our breakdown of custom web app costs explains what moves that number. We work from a written fixed-price scope per phase, demo weekly and test on your real data. You own the code, accounts and data. More on our approach is on the custom web apps page.

If your team spends hours a week sending customers copies of invoices, order updates or documents, book a free 45-minute consultation. We will look at your ERP or CRM, tell you whether the built-in portal is enough, and outline a first phase if it is not.