Your portal. Inside your product.

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 in the embedded portal reads from these tokens — buttons, sidebar navigation, cards, status badges, input fields, and modals.

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 sidebar shows your company name and initials, not the Apitide wordmark. Page titles reflect your company name. There is no "Powered by Apitide" attribution in the embedded view — the portal appears as a native part of your product to end users.

The embedded portal is authenticated via a signed JWT issued by your backend. You call the Apitide 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 or pass it as a query parameter and Apitide validates it, creates a scoped session, and renders the portal for that customer.

The token is signed with a secret you control. Apitide 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, Apitide 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.

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.