White-Label Branding — Guide

How to put your company’s brand on the Solidlio portal, its emails and the pages your clients see, and what happens at each level of the cascade.

What it is

Branding is a set of visual settings — logo, colours, fonts, corner radius, theme rules — stored at three levels and merged into one resolved brand at read time. The level that supplies the brand also supplies the legal identity that appears in the footer of every email sent under it.

Two separate plan entitlements govern it. customBranding decides whether you may set anything; whiteLabel decides only whether the “Powered by Solidlio” attribution is removed from underneath what you set.

Concepts

The cascade in practice

Each level stores only what it changes. If the platform sets a primary colour and your MSP sets a logo, an organization under that MSP resolves the MSP’s logo and the platform’s colour — with no row of its own.

Nested groups (darkMode, lightMode, fonts, darkColors, lightColors) merge field by field, not wholesale. An MSP can set darkMode.background while an organization overrides only darkMode.textColor; both survive.

Which account is the MSP level

This is the rule that makes an MSP’s brand reach its clients at all.

When you create a managed client, that client gets an Account of its own, with managedByAccountId pointing at you. The client’s organizations hang off that account. So “the account this organization belongs to” is the client’s container, not your branding level — nobody ever writes branding against a client container.

The MSP level therefore resolves from managedByAccountId ?? id. One hop, deliberately: the level above an MSP is the platform, which the cascade already supplies.

Three things resolve from that same account and must not diverge: the branding overrides, the entitlement that gates them, and the legal identity the footer prints. Splitting them is how you get an MSP’s logo above a client’s legal name.

Roles and permissions

Reading the brand you are already looking at is not a privilege, so every authenticated role can read the cascade.

Without the second check an organization admin could post scope=platform and replace the logo every tenant on every portal sees. Nothing is written before that check runs.

Walkthroughs

Brand your MSP (and every client you manage)

MSP portal → Settings → Branding (/msp/settings/branding)

1. Complete your sender identity first. If it is incomplete the branding form is locked with a notice listing the exact missing fields, and links to Settings → Sender Identity (/msp/settings/sender-identity). You need a legal name, a street address, and at least one of website, email or phone.
2. Company name. This is the display name in the portal header, the email From line, the subject line and the logo’s alt text. A level that uploads a logo but sets no company name supplies no brand at all in email — there is no name to put beside the logo that is its own, so the logo falls through with it. Set it.
3. Logo. A wide wordmark for light surfaces. Recommended max 400×120px.
4. Logo (dark surfaces). The light-ink version, for dark sidebars and dark-mode emails. Optional — when absent the light logo is used on a white chip so it stays legible rather than vanishing.
5. Icon. A square mark for compact chrome: the portal header, the collapsed sidebar, and the browser tab when no favicon is set. A wide wordmark squeezed into a square slot looks wrong; this is the fix.
6. Favicon. Square, 32×32 or 64×64.
7. Colours. One hex each for primary, secondary and accent. Each generates an 11-shade scale shown beneath the picker.
8. Theme mode. Dark only, Light only, or Both. With Both, pick the default new users land on. Dark-only and light-only remove the theme toggle from the portal chrome entirely.
9. Fonts and corner radius. 13 curated Google Fonts; five radius presets.
10. Save. The portal re-skins immediately, every other open portal re-resolves without a reload, and the email brand cache is dropped.

Everything you set here now resolves for every organization your account manages, on their portal, in their email and on their public survey pages — unless that organization sets its own.

Brand a single organization

Organization portal → Settings → Branding (/org/settings/branding)

Identical form, one level down. Each control shows where its current value came from and offers Reset when you have overridden it.

• A badge reading Platform Default or MSP Override means the field is inherited. The preview shows the inherited value greyed.
• Once you change a field the badge becomes Custom and a Reset link appears. Reset removes your override and the field inherits again.
• Reset all at the bottom clears every override at once. Resetting is always allowed regardless of plan — it removes customisation rather than adding it.

Set the platform defaults

Platform admin → Settings → Branding (/platform/settings/branding)

The bottom of the cascade, and what every tenant without an override resolves to. All four assets, all colours, fonts, radius and theme rules. There is no per-field reset here — this level has nothing to inherit from.

Saving writes a platform audit-log entry with your identity, the previous state and the new state, and signals every open portal to re-resolve.

Remove the Solidlio attribution

Nothing to configure. On an Enterprise plan the whiteLabel flag is on and the attribution stops rendering everywhere it appears:

• the portal sidebar, under your company name
• the customer portal sidebar
• the custom-domain login card
• the footer of every email
• the satisfaction survey page your clients fill in
• the recovery-codes PDF

If you are on Scale or Business you can brand fully or by logo, and the attribution stays. That is what the Enterprise tier’s white-label line buys.

What a client’s end user sees

A managed client’s own customers never sign in. They meet your brand on:

• The activation link — your logo on the set-a-password screen.
• Every transactional email — your logo, your colours, your name in the From line, your legal entity in the footer.
• The document-signing page — your mark above the documents they are asked to sign.
• The satisfaction survey — your mark and your accent colour, and no Solidlio footer if you are white-label.

Configuration

Every field, what it does, and what happens if you leave it unset.

Colour validation. Every colour must be #rrggbb. Values are validated server-side on write and again client-side before being written into a CSS variable.

Font allowlist. Only these 13 are accepted, server-side and client-side: Inter, DM Sans, Plus Jakarta Sans, Outfit, Manrope, Space Grotesk, Sora, Nunito Sans, Poppins, Raleway, Merriweather, Playfair Display, Lora.

Asset uploads. 2MB maximum. PNG, JPEG, SVG, WebP, ICO. Uploading a replacement frees the blob the field previously pointed at, so at most one blob per scope and type survives.

SVG in email. Gmail and Outlook do not render SVG. An SVG logo is accepted for the portal but dropped from email, which falls back to your company name as styled text rather than showing a broken image.

Plan tiers

customBranding is a ladder; whiteLabel is a boolean. They are independent.

LOGO_ONLY permits exactly four fields: logo, logoDark, icon, companyName. Every other field is locked in the form and refused by the API.

Both gates fail closed. An account with no service tier, or a tier whose features omits customBranding, resolves to false — no branding — never to full access. whiteLabel requires an explicit true; anything else leaves the attribution in place.

Entitlement follows the brand. For a managed client, whiteLabel is read from the MSP’s tier, because the brand on that portal is the MSP’s.

Troubleshooting

“Your plan does not include custom branding. Upgrade to customize.” HTTP 403 with an upgrade envelope. Your account’s tier has customBranding: false. The envelope names the cheapest tier in your group that unlocks it. Clearing overrides is still allowed on any plan.

“Your plan only allows logo and company name customization. Upgrade to customize: primaryColor, fonts” HTTP 403. You are on LOGO_ONLY and sent a field outside logo, logoDark, icon, companyName. The message lists exactly which fields were refused.

403 SENDER_IDENTITY_REQUIRED with details.missingFields You have no complete legal identity. Fill the named fields at Settings → Sender Identity — /msp/settings/sender-identity for the account tier, /org/settings/sender-identity for the organization tier. This sits after the plan gate on purpose: an unentitled tenant should hear about its plan, not about an identity it does not yet need.

“Unsupported file type: image/gif. Allowed: PNG, JPEG, SVG, WebP, ICO” HTTP 400 from the upload route’s MIME allowlist.

“File too large” HTTP 413. The cap is 2MB.

“Scope must be ‘platform’, ‘msp’, or ‘organization’.” HTTP 400 from the upload route.

“Uploading platform-scoped branding requires platform administrator.” HTTP 403. The scope you asked for outranks your role.

“Type must be ‘logo’, ‘logoDark’, ‘favicon’, or ‘icon’.” HTTP 400 from the upload route.

“Must be a valid hex color” HTTP 400. Colours must be #rrggbb — six digits, with the hash.

“Must be an absolute http(s) URL or a relative /path” HTTP 400 on a logo field. Paste a full https://… URL or leave the relative proxy path the upload returned exactly as it is.

My logo shows in the portal but not in my email. Three causes, in order of likelihood. (2) Your level set a logo but no companyName, so it is not the brand level and its logo falls through with it — logged as “a tier supplied a LOGO but no companyName”. (3) Your logo is an SVG, which email clients do not render; upload a PNG.

A client’s portal shows the platform’s brand instead of ours. Check that the client account’s managedByAccountId points at your account.

I saved and the portal still shows the old logo. The portal re-resolves on save and on the branding-updated event. If you are looking at a different browser tab that predates the save, it will pick the change up on its own; a hard reload forces it. Email carries a 5-minute cache that a branding write invalidates immediately.

“Powered by Solidlio” still appears after upgrading to Enterprise. The flag is read from the branding account. If you are a managed client, it is your MSP’s plan that decides — upgrading the client account does not suppress an MSP-supplied brand’s attribution.

Limits and known behaviour

• Two hex digits per colour role, not a full palette. You pick one hex per role; the 11 shades are generated. You cannot hand-tune an individual shade.
• Contrast is not guaranteed. Brand colours are tenant-supplied and rewritten at runtime. The product computes a readable text colour on each brand surface it generates, but it does not validate the brand colour itself against a contrast target — a low-contrast brand colour will render as chosen. Pick colours you have checked.
• themeMode and defaultTheme only bind in the portal chrome. They control the portal’s theme toggle and starting theme. They do not affect email, which always renders light with an optional dark-surface logo.
• The palette suggestion is offered where colours are editable. The button is disabled on LOGO_ONLY and unentitled plans.
• One CustomDomain row backs organization branding. Where an organization holds several, readers and writers all use the same deterministic order (oldest first, then by id) so the portal and the email cannot land on different rows.
• The platform level has no reset. There is nothing beneath it to inherit from; clear a field by emptying it.
• Uploads reap their predecessor, not their history. Replacing a logo frees the previous blob. A blob orphaned by a failed reap is logged and left; it is not retried.
• No per-portal brand. One brand per level applies to the MSP portal, the organization portal and the customer portal alike. You cannot give the customer portal different colours from the staff portal.
• The portal-error page is always platform-branded, by necessity. It is shown when a hostname cannot be resolved to a portal — so at that moment there is no tenant to brand as. Every other unauthenticated page follows the tenant on their own domain: login, signup, password reset, email verification, MFA verification and setup, invite acceptance, profile completion, activation, document signing, the satisfaction survey and the 404 page. On a white-label plan the 404 also drops the Solidlio footer and support link, and its call to action stays on the tenant’s domain instead of linking to solidlio.com.
• Generated PDFs other than recovery codes are platform-branded. Quote, invoice and SOW PDFs render with the platform’s header and colours; only the recovery-codes PDF follows the tenant brand and the whiteLabel flag.