What You Can and Cannot Build with HubSpot Memberships (and What Needs Custom Code)

If you are evaluating HubSpot memberships to build a gated members area or a customer portal, you need an honest capability map before you commit a budget. Memberships are genuinely useful, but they are a content-gating system first and a self-service application a distant second. Knowing exactly where the native feature ends, and where custom engineering has to begin, is the difference between a project that ships and one that stalls halfway through.

This guide walks through what HubSpot memberships do well out of the box, the limits that catch teams out, and the points where serverless functions, custom objects and proper single sign-on configuration extend memberships into something that actually behaves like a portal. We are a UK HubSpot Diamond Partner and an engineering firm, so this is written from the build side of the table.

What HubSpot memberships actually are

It helps to get the terminology right, because HubSpot uses several overlapping terms. "Memberships" is the native system for gating private content. It works through access groups (the mechanism that decides who can see what) plus member registration, where a contact sets their own password and logs in.

There are two distinct surfaces, and they sit in different hubs:

• Website pages and blog posts are gated through Content Hub.
• Knowledge base articles and the Service Hub customer portal are gated through Service Hub.

This is not a Marketing Hub or Sales Hub feature, which trips up a lot of teams during scoping. Access groups and memberships require Content Hub Professional or Enterprise (for pages and blogs), or Service Hub Professional or Enterprise (for the knowledge base and customer portal).

One verified caveat worth flagging if you are on an older contract: accounts on a legacy CMS Hub Professional subscription do not support memberships, even though current Content Hub Professional does. If you signed up some years ago, confirm what your specific subscription includes before you scope anything.

What native memberships do well

Used for what they are designed for, memberships are solid. Out of the box you can:

• Create static access groups (where you add contacts or segments manually) or dynamic groups that auto-populate based on filters against CRM properties.
• Send registration emails automatically when content is made private, so contacts set their own password and log in.
• Restrict access across website pages, blog posts, knowledge base articles and the customer portal.
• Export membership data and analytics for reporting.
• Configure single sign-on using a SAML 2.0 identity provider such as Okta, Microsoft Entra or OneLogin, with the option to require both identity-provider membership and HubSpot contact-list membership for tiered access.
• Display a logged-in contact's own CRM data on a gated page using HubL, including associated records such as a contact's deals. Any CRM object type can be surfaced this way, but only on a page that is password-protected or behind a membership login (product objects are the exception).

For a straightforward gated resource library, a partner portal showing each contact their own records, or a knowledge base only customers can read, native memberships will often get you most of the way there.

The native limits that catch teams out

The honest "cannot" list is where scoping conversations earn their keep. These are verified constraints, not opinion.

Single sign-on and access groups

HubSpot's documentation states that for memberships SSO it supports SAML-based applications only. If your identity stack expects a different protocol, that is a gap to plan around. Account-level SSO is generally an Enterprise feature, and the membership SSO for content needs Professional or Enterprise Content or Service Hub. On the access-group side, the Professional tier is capped at two access groups, which is a real ceiling if you want anything more than a couple of tiers. Enterprise lifts this to as many as one hundred groups. Treat these caps as current but subject to change, and confirm against your own account.

Registration, notifications and domains

A few behaviours surprise teams in production. When you first link an access group to content, HubSpot will send up to 25,000 registration emails. A contact receives only one registration email, and does not get further emails as new content becomes accessible to them, which is an onboarding gap for a portal whose content keeps growing. Private content also requires a connected custom subdomain, because HubSpot default domains are not supported.

Security and the customer portal

Password-protected content is not indexed, but in HubSpot's own wording the sensitive data is not encrypted, which matters if your portal holds genuinely sensitive information. The native customer portal carries its own constraints too: multi-language portals are not supported, only ticket-associated conversations appear (chat, Messenger, form and team-email messages that are not tied to a ticket do not show), and with sensitive-data settings enabled, attachments cannot be viewed outside HubSpot, so customers cannot see those files in the portal. Beyond that, customisation of the knowledge base and ticket-management flexibility are widely reported as limited, so verify the specifics against your requirements.

Where custom engineering turns memberships into a real portal

This is the payoff. Native memberships gate content and show a contact their own basic CRM data. They do not give you a true self-service application that writes data back, models your business objects or integrates with your other systems. Custom code closes that gap, and this is the work that sits behind our HubSpot CMS memberships service.

Serverless functions for back-end logic. On Content Hub Enterprise, serverless functions let you run server-side code: writing form submissions back to the CRM, calling third-party APIs, performing gated data operations and generating dynamic content. There are limits to design around (each function runs for up to ten seconds, with a per-account ceiling of 600 total execution seconds per minute and a limit on the number of endpoints), and the project framework for serverless has moved quickly through recent platform versions, so the implementation detail is fast-moving and worth confirming at build time.

Custom objects to model real portal data. HubSpot has no native object for things like orders, projects, assets or entitlements. Custom objects, surfaced per logged-in contact through HubL behind the membership login, let you build a portal around the data your business actually runs on rather than bending everything into contacts and deals.

Single sign-on configuration. Wiring HubSpot to your SAML 2.0 identity provider for a seamless login is configuration and engineering work, not a click-to-enable toggle. Getting the access modes and tiering right is part of the build.

When requirements run past the native ceilings (more than two groups on Professional, encryption of genuinely sensitive data, multi-language portals, complex permissioning, or substantial write-back), the honest answer is that you have outgrown native memberships and need engineered, owned infrastructure. That is the line where a HubSpot-hosted gated area becomes a proper application, and it is exactly the build we cover on our customer portals page and our wider HubSpot development service.

So, build, extend or buy?

A useful rule of thumb: if you need to gate existing HubSpot content and show contacts their own records, native memberships are likely enough, and you should resist over-engineering. If you need write-back, custom data models, integrations or anything past the tier ceilings, plan for custom code from the start rather than discovering the wall mid-project. If you are weighing whether to build at all, our guides on what you can build with custom HubSpot development and how much a HubSpot developer costs in the UK are good companion reads.

Indicative pricing for the engineering layer, framed as a starting point: a CMS membership portal from £15,000, and serverless functions from £2,000. The right answer always depends on the data model and integrations, not just the gate.

Talk to engineers, not configurators

If you are deciding whether HubSpot memberships can carry your portal, or where the custom-code line really sits for your use case, we can map it honestly before you spend. As a UK HubSpot Diamond Partner with an in-house engineering team, we build productised, client-owned solutions and back delivery with a guarantee: on time, or you get 20% back. Request a quote and we will tell you what native can do and what it cannot, with no upsell to a build you do not need.

Frequently asked questions

What HubSpot subscription do I need for memberships?

Access groups and memberships require Content Hub Professional or Enterprise to gate website pages and blog posts, or Service Hub Professional or Enterprise to gate knowledge base articles and the customer portal. Note that a legacy CMS Hub Professional subscription does not support memberships, even though current Content Hub Professional does, so confirm what your specific contract includes. Serverless functions, used for custom back-end logic, require Content Hub Enterprise specifically.

Can HubSpot memberships show a contact their own CRM data?

Yes. Using HubL on a page that is password-protected or behind a membership login, you can render the logged-in contact's own CRM data and associated records, such as their deals. Any CRM object type can be surfaced this way except product objects. What native memberships cannot do well is write data back or model objects HubSpot has no native type for, which is where custom objects and serverless functions come in.

What single sign-on does HubSpot memberships support?

HubSpot's documentation states that memberships single sign-on supports SAML 2.0 identity providers only, with Okta, Microsoft Entra and OneLogin documented. You can require either any identity-provider user assigned in HubSpot, or both identity-provider membership and HubSpot contact-list membership for tiered access. Wiring HubSpot to your identity provider is configuration and engineering work rather than a simple toggle.

What are the main limitations of the native HubSpot customer portal?

Verified limits include no multi-language support, only ticket-associated conversations appearing (chat, Messenger, form and team-email messages not tied to a ticket are not shown), and, with sensitive-data settings enabled, attachments not being viewable in the portal. Knowledge base customisation and ticket-management flexibility are also widely reported as limited. Where these constraints block your requirements, the answer is usually engineered, owned infrastructure rather than the native portal.

When do I need custom code instead of native memberships?

You need custom engineering once you go past what native gating offers: writing data back to the CRM, calling third-party APIs, modelling business objects such as orders or projects with custom objects, going beyond the two access groups allowed on Professional, encrypting genuinely sensitive data, or running a multi-language portal. At that point serverless functions on Content Hub Enterprise and a proper data model turn a gated content area into a real self-service application.