Your portal. Inside your product.

Your logo, colours, fonts, and shape — zero younifyd branding visible

The embedded portal inherits a complete design token system: primary and secondary colours, background and surface colours, text colours, border colours, button text colour, font family, and border radius. Every visual element inside the portal reads from these tokens — buttons, cards, status badges, input fields, and modals — and there is no "Powered by younifyd" attribution anywhere in that content.

Configure tokens once per organisation in the White Label settings panel. The portal preview updates in real time so you can see exactly how your brand configuration renders before issuing any tokens to customers. The preview is a live iframe — not a mockup — so what you see is what your customers will see.

The portal itself renders inside your product with no younifyd-branded chrome around it. You build the surrounding page — your own sidebar, your own navigation — and the iframe drops into it, themed to match.

100%younifyd branding removed

Point each organisation's portal at the sections that matter to them

Not every client needs every part of the platform front and center. Configure which capabilities — Workflows, Connections, MCP Servers, Access Control, Analytics, Executions, Published — are relevant for an organisation, and its embedded portal's default landing and navigation reflect that configuration.

This is configured per organisation today. If you need different visibility for different user roles within the same embedded client, combine it with your own role and permission model on top — capability configuration sets the default experience, your own auth layer decides who reaches what.

org-levelcapability configuration

Issue tokens from your backend — younifyd never sees your customers' credentials

The embedded portal is authenticated via a signed JWT issued by your backend. You call the younifyd embed token endpoint from your server — passing the customer's store name, role, and optional user identity fields — and receive a short-lived signed token. Embed that token in the iframe URL and younifyd validates it, creates a scoped session, and renders the portal for that customer.

The token is signed with a secret you control. younifyd validates the signature but never needs to know anything about the customer beyond what is in the token. Your authentication system remains authoritative — customers log in to your product via whatever method you use, and your backend decides when to issue an embed token.

Store provisioning is automatic. If the store name in the token does not exist in your organisation yet, younifyd creates it on first use. Subsequent tokens for the same store name resolve to the same store — no pre-provisioning step, no manual store setup per customer. This makes embedding suitable for multi-tenant SaaS products where customer environments are created on demand.

signed JWTyour backend stays authoritative

The portal only loads inside your domains — prevents unauthorised embedding

Embed tokens are powerful credentials — they grant access to a customer's store with the capabilities and role encoded in the token. Allowing any website to embed the portal would let an attacker who obtains a token embed it in their own page and operate on behalf of the customer.

younifyd enforces an allowlist of domains that are permitted to embed the portal. Configure your domains in the White Label settings — the embedded portal checks the parent frame's origin against this list on load. If the origin does not match, the portal refuses to render and displays an access denied message instead.

The domain check uses the browser's ancestorOrigins API (with a document.referrer fallback for browsers that don't expose ancestor origins) — the same mechanism browsers use for Content Security Policy frame-ancestors enforcement. Configure as many allowed domains as you need — typically your production domain, a staging domain, and a local development origin.

allowlistdomains that can embed the portal

Pixel-perfect control for integrations that need to go beyond design tokens

Design tokens cover the common customisation surface — colours, fonts, shape, spacing. But some integrations need more: remove a specific UI element, override a component's layout to fit a constrained sidebar, match a design system that uses custom focus ring styles or unusual button shapes.

The White Label configuration includes a raw CSS field that is injected into the embedded portal's scope on load. CSS custom properties from your token configuration are available as var(--embed-primary), var(--embed-secondary), and so on, so your override rules can reference the configured brand values rather than hardcoding hex codes.

The injected CSS is scoped to the embedded portal root element — it does not leak into the parent page. This means you can use aggressive selectors (including element selectors like button and input) inside the override block without worrying about affecting your product's own styles. The parent page and the embedded portal have completely isolated CSS scopes.

scopedcustom CSS — no parent page leakage