Skip to content
SolutionArg

CMS

Building a Client Portal on HubSpot: Options, Costs and Trade-offs

Four ways to give clients a logged-in portal on HubSpot: support portal, memberships, CMS serverless or an external app, with plan needs and limits.

By SolutionArg6 min read

TL;DR

  • Support portal (the successor to the legacy customer portal): ticket-only, needs Service Hub Professional or Enterprise (HubSpot KB).
  • Memberships / private content on HubSpot CMS: logged-in pages driven by CRM lists. Needs Content Hub or Service Hub Professional/Enterprise (HubSpot KB).
  • CMS + serverless functions: interactive portals (uploads, forms that write to deals) on HubSpot hosting. Needs Content Hub Enterprise, with strict execution limits (HubSpot Developers).
  • External app (for example Next.js) using HubSpot's APIs: the most flexible, but you host it and handle authentication yourself.
  • Pick the lightest option that covers what clients need to do, not just see.

Start with what clients need to do

"Client portal" means very different things:

  • See their support tickets → a ticket portal is enough.
  • Read private documents, guides or updates → memberships.
  • Do things: upload files, approve a quote, update details, see project status from deals or custom objects → you need logic behind the page.

Write down the three to five actions a client must perform. That list decides your option and budget far more than design does.

Option 1 — HubSpot support portal

What it is. A logged-in area where customers view and follow their tickets. HubSpot's KB describes it as showing tickets only (HubSpot KB).

Plan. Service Hub Professional or Enterprise.

Good for. Support-led businesses that want clients to track requests. Not for. Project dashboards, documents tied to deals, or custom workflows.

Option 2 — Memberships (private content) on HubSpot CMS

What it is. Pages, blogs or knowledge base articles that only contacts on specific CRM lists can access. When contacts are granted access, they receive an email to register and set a password (HubSpot Developers — memberships).

Plan. Service Hub or Content Hub, Professional or Enterprise. The legacy CMS Hub Professional doesn't support memberships (HubSpot KB).

What developers can do.

  • request_contact.is_logged_in tells your HubL template whether the visitor is signed in.
  • request_contact.list_memberships returns the lists they belong to, so one page can show different content to different clients (HubSpot Developers).

CRM data on pages.

  • For security, only product and marketing event objects can be retrieved on public pages.
  • Other object types (contacts, deals, tickets and so on) need a page behind a password or membership login.
  • Custom objects in CMS pages require Content Hub Enterprise (HubSpot Developers — CRM objects in CMS).

Good for. Read-mostly portals: onboarding guides, deliverables, account details.

Option 3 — CMS pages + serverless functions

What it is. Memberships, plus small server-side functions that run on HubSpot. They let a logged-in client write data: upload a file, update a deal, submit a request.

Plan. Content Hub Enterprise (HubSpot Developers — getting started).

Limits to design around (HubSpot Developers):

LimitValue
Execution time per function10 seconds
Account-wide execution600 execution-seconds per minute (429 when exceeded)
Memory128 MB
Payload per invocation6 MB (relevant for file uploads)
Endpoints per account100
Secrets per account50
Logging4 KB of log data

What I've built this way

  • Sales portal. Built with HubL and custom landing pages for company owners and sales reps who don't have direct access to HubSpot. Reps log in to create, track and update deals, and upload files, images and videos that are associated with the deal records.
  • Client portal with custom cards, serverless functions and React. Each deal has a card that creates folders, uploads files and generates a secure password. The portal then displays the right files to each client on the website.
  • Real-estate portal on HubSpot CMS. Custom drag-and-drop modules for no-code editing, with property information updated automatically via deals.

These projects show the pattern: HubSpot remains the system of record, and the portal is a controlled window onto specific deals.

Good for. Portals where clients or reps act on CRM data and you want everything inside HubSpot. Watch out for. The 6 MB payload limit for uploads, and the 10-second limit for anything slow.

Option 4 — External app on your own stack

What it is. A separate web app (Next.js, for example) with its own login, calling HubSpot's APIs from your server.

Plan. No specific HubSpot tier for the portal itself, but you're bound by API rate limits:

  • 100 requests per 10 seconds on Free/Starter;
  • 190 on Professional/Enterprise;
  • daily caps by tier.

(HubSpot usage guidelines)

Good for. Complex UX, heavy file handling, other data sources, or teams that already run a web app. Watch out for.

  • You own authentication, security, hosting and uptime.
  • Cache aggressively, because every page view could become an API call.

How to choose

You need…Lightest option
Clients to see their ticketsSupport portal (Service Hub Pro+)
Private pages by client or segmentMemberships (Content/Service Hub Pro+)
Clients to upload or update CRM data, all inside HubSpotCMS + serverless (Content Hub Enterprise)
Complex UX, big files, multiple systemsExternal app + HubSpot API

Costs: what actually drives them

I won't quote HubSpot list prices here; they change, so check HubSpot's pricing page for your hubs. What drives the build cost:

  1. Number of client actions. Each action is a form, a function and a test case.
  2. Data model. Deals and standard objects are simpler; custom objects add Enterprise requirements on CMS.
  3. File handling. Size limits and storage decisions.
  4. Who logs in. Clients, reps or partners, and how access is granted (lists, deal association, password).

A phased approach that keeps risk low

You don't have to pick the final architecture on day one:

  1. Phase 1 — read-only. Launch memberships pages showing each client's documents and status from deal properties. You'll learn which information clients actually open.
  2. Phase 2 — one write action. Add the single most requested action, usually a file upload or a request form, through a serverless function or your own endpoint.
  3. Phase 3 — expand or move out. If the action list keeps growing, or the limits above start to bite, move the heavy parts to an external app while keeping HubSpot as the system of record.

Each phase delivers something usable, and nothing is thrown away when you move to the next.

Security basics, whatever you choose

  • Grant access by list membership or association, never by guessable URLs alone.
  • Keep tokens in serverless secrets or server-side environment variables, never in page code.
  • Log what clients change, and keep a human-readable audit trail on the deal.

Sources

FAQ

Does HubSpot have a built-in client portal? Yes, the support portal, but it shows tickets only and needs Service Hub Professional or Enterprise.

Can I show deal data on a HubSpot page? Only on pages behind a password or membership login. Public pages can only retrieve products and marketing events.

What plan do I need for a portal where clients upload files? On HubSpot hosting, plan for Content Hub Enterprise (serverless functions) and memberships. Otherwise, build an external app on the API.

Is the legacy CMS Hub Professional enough for memberships? No. HubSpot states legacy CMS Hub Professional doesn't support memberships.

Let's find the manual work hiding in your HubSpot.

30 minutes. You show me how things work today; I'll tell you what I'd fix first and roughly what it takes — no pitch deck.

Send a messageSee case studies

Almost always reply within 24 hours