HubSpot + Custom portals integration

The request usually arrives as a support problem. Members email to ask when the next event is, partners email to ask what happened to the referral they sent three weeks ago, and clients email to ask for the document they were sent in March. Every one of those answers already exists in the CRM. None of them is visible to the person who wants it, so a human has to look it up and reply.

The obvious fix is a portal, and the obvious mistake is buying one that keeps its own database. That gives the team two places to update a record, two places for a stage to be wrong, and a nightly reconciliation nobody signed up for. What people actually want is a window: the CRM stays the only place the team works, and the portal shows each person their own slice of it.

That is what we build. The portal has no database of record. It holds a session, a cache and a little bookkeeping of its own, like which notification somebody has read. Everything else is HubSpot, read live and written live. A referral submitted in the portal is a deal in a pipeline within a second, and when the team moves that deal the portal shows the new stage on the next read.

We run this engine for our own partner referral portal and built the same foundation for a membership organization’s member portal. The screens and the object model differ every time. The engine, the security model and the caching strategy have carried across every build so far.

The mapping is unusual on this page, because HubSpot is the source and the portal is the surface. A person signing in is a contact, and an access property on that contact decides whether they may sign in at all, so offboarding somebody is a CRM change rather than a support ticket.

A submission becomes a native object, not a custom one. A referral or a request is a deal in its own pipeline, because the team already knows how to work a pipeline and because stage history is then free: reading the deal’s stage history back gives the portal a tracker with a date against each step.

Content that the team publishes is custom object records: resources, events, notifications. Documents pair a custom object record with a file. Portal behaviour goes back the other way as custom behavioural events, so sign-ins and views land on the contact timeline beside emails and calls.

The browser holds a session cookie and nothing else. Every request hits our own server-side functions, which resolve the signed-in contact, check the access property, check that the record being requested actually belongs to that contact, then read HubSpot through a cache.

Caching is the load-bearing part. HubSpot’s limits are counted per app, so every signed-in user draws on one shared budget. Lists that are identical for everyone, a resource library for example, are cached once globally. Per-person reads are cached briefly and invalidated the moment that person writes something, so a submission appears immediately while a colleague’s unrelated read still comes from cache.

Our own small database holds only what HubSpot should not: session records, a sign-in audit, notification read state. Losing it would cost a few sessions and nothing of record.

The choice is mostly about what the portal has to do. If the requirement is gated content, HubSpot’s own membership features already do that and a build is unnecessary. If the requirement is records, stages, uploads, a per-person pipeline view and a branded experience on a phone, that is a build.

The third route, a packaged portal product, is the one we advise against when HubSpot is already the CRM. Those products keep their own copy of the data and sync it, which turns a one-system problem into a two-system problem and puts a vendor between the team and the records they work all day.

Reuse changes the arithmetic. The second portal on an engine that already exists costs a fraction of the first, which is why we keep one foundation rather than starting each build fresh.

1. Scope. We work out who signs in, what each person may see, and which of those things already exist as records in the portal.
2. Architect. The object model first, deciding what is a native object, what is a custom object and what is only a property, then the caching plan that follows from the read pattern.
3. Build. Server-side functions with the credential in a secret store, a branded interface on top, and the whole thing runnable locally against fixtures so development never touches live data.
4. Validate. A sandbox portal seeded by an idempotent script, guarded so it refuses to run against production.
5. Operate. Sign-in audit, error alerting, and a quarterly look at the request volume against the account’s limits.