Giving clients a portal into their own documentation is one of the easiest wins an MSP can ship. It also creates a security boundary that most platforms get subtly wrong: they hide internal data in the interface, but still send it to the browser.
The difference matters. If a client-facing page fetches a full asset record and the UI simply doesn’t render the internal fields, the data is one “Inspect → Network tab” away from any curious client user. That’s not access control — it’s a curtain.
Weavestream’s client portal takes the other approach. Anything not explicitly marked as visible to clients is stripped from the response payload on the server, before it ever leaves your instance. There’s nothing to find in the network traffic because the data was never sent.
The Difference Between Hiding and Not Sending
Client-side filtering is a common shortcut in web applications: fetch everything, render some of it. It’s faster to build and it looks identical to the end user — right up until someone opens developer tools.
For an MSP, the stakes are specific. A client’s asset record might carry a mix of fields: the office printer’s model and location (fine to share), and the internal notes about the workaround for its broken firmware, the management VLAN, or the local admin username (not fine). If your documentation platform sends all of that to the client’s browser and hides half of it with CSS, your “internal-only” fields are internal in name only.
Weavestream enforces field-level visibility at the API layer. When an asset record is fetched for the client portal, every field marked visibleToClients = false is removed from the payload server-side. A client user inspecting network traffic sees exactly what they see on screen — nothing more.
What Gets Scoped, and Where You Control It
Every tenant in Weavestream has a dedicated portal at /portal/<company-slug>, and client users only reach the companies they hold memberships on. Within the portal, visibility is controlled per entity, from the admin UI you already use:
- Articles — a
visibleToClientstoggle on each article. Internal runbooks stay internal; the client-facing onboarding guide goes to the portal. - Asset fields — visibility is set per field in the layout builder. One layout serves both audiences: technicians see every field, clients see only the fields you’ve opted in.
- Passwords — a per-record toggle. More on this below.
- Domains — per-domain visibility, so clients can watch their own SSL and registration status without seeing anything else you monitor.
There’s no separate content system to maintain and no duplicated records. You mark what’s shareable, and the server does the enforcement.
Passwords Are Private by Default
Credentials are the highest-stakes records in the portal, and Weavestream treats them that way. New passwords default to not visible in the client portal — sharing one requires an explicit opt-in, and flipping the toggle shows an inline warning that client portal users will be able to see and reveal the credential. Nobody shares a credential with a client by accident.
For the passwords you do share — a Wi-Fi passphrase, a vendor portal login the client owns — the same access controls apply in the portal as in the admin vault:
- Reveal audit trail — every decryption is logged with actor, timestamp, and IP, whether it happens in the admin interface or the portal.
- Reason-to-view prompts — if a credential requires a justification before reveal, client users are prompted too.
- User whitelists — restricted credentials stay restricted, regardless of which interface is asking.
The portal isn’t a side door into the vault. It’s the same vault, behind the same policy checks, with an extra visibility gate in front.
Version History Doesn’t Leak Either
Here’s an edge case most platforms never think about: an article that used to contain internal information, was cleaned up, and was then shared to the portal. Can the client browse the version history and read the old internal draft?
In Weavestream, no. Article version history is gated per version’s own visibility — portal users only see historical versions that were themselves marked client-visible at the time they were written, even if the article is currently client-visible. Hidden versions return a 404 with no existence disclosure, so a client can’t even tell that earlier internal drafts exist. Operators, meanwhile, keep the full history.
The same thinking extends to file attachments. Uploads declare a parent — an asset, article, asset field, or password — and the server verifies the parent exists, belongs to the same company, and (for password attachments) is actually readable by the requesting user before the file is served. Non-image files are delivered as downloads with browser caching disabled, so a sensitive PDF viewed once doesn’t linger in a client machine’s disk cache.
Client Users Are Real Accounts, Not Shared Links
Server-side scoping only means something if you know who’s on the other end. Weavestream’s portal has no anonymous access and no magic links. Client users are invite-only accounts, created by an admin and set up through a one-time token — and forced TOTP MFA applies to them exactly as it does to your technicians. There is no bypass.
Within a tenant, two portal roles cover the usual cases: CLIENT_ADMIN can view all client-visible content and manage the other client users in their own company, while CLIENT_VIEWER is strictly read-only. Neither role can touch the admin interface — any request to an /admin route returns a 403.
That structure means portal activity is attributable. When a client-visible credential is revealed, the audit log names the specific person, not “the client.”
Check Your Work: Preview the Portal as an Admin
Trust but verify. Operators with admin access can load any tenant’s portal at /portal/<slug> and walk it in the exact shape a client would see — same server-side scoping, same visibility rules, read-only by design. Before you hand a portal login to a client, you can click through every page and confirm that what’s visible is what you intended, without creating a test client account.
It’s a small feature, but it closes the loop: the visibility model is enforced on the server, and you can inspect the result through the same enforcement path your clients use.
Why This Matters for Compliance
If you’re working toward SOC 2 or ISO 27001, or answering a client security questionnaire, “clients can only access data explicitly shared with them” is a claim you’ll need to stand behind. Client-side hiding makes that claim false in a way an auditor — or a curious client employee — can demonstrate in about thirty seconds.
Server-side field scoping makes it true by construction. Combined with forced MFA on portal accounts, per-record visibility flags, version-aware history gating, and the reveal audit trail, Weavestream gives you a client access story you can document and defend: what a client can’t see, their browser never receives.
And because Weavestream is self-hosted, the entire boundary runs on your infrastructure. No SaaS middle layer, no per-seat portal fees, no third party between your clients and their data.
Weavestream is free, self-hosted, and open source. The client portal and server-side field scoping described here are available in every deployment, with no add-on required. Find out more at weavestream.io.