Skip to main content

Whitelabel — Unified Branding Service

Give Qontak Chat a single source of truth for branding — logo, colors, product name, favicon, fonts, and support/legal links — so every frontend (hub-chat, crm-fe-v3) and backend (email/PDF renderers) can theme per tenant without reimplementing theming per service.

The key insight from the source design is that hub-chat and crm-fe-v3 both render through the same @mekari/pixel3 --mp-colors-* CSS variables, so one set of token overrides themes both apps with no per-component logic. Unification is a thin consumption layer over what already exists — a branding store + resolver in hub_core, a public GET /branding endpoint in hub_service, and a small applyBranding composable on each frontend.

Source design (Confluence): Whitelabel — Unified Branding Service (Design) — author A. Firdha Shafridhi (Saf). DRI to be assigned.

Structure

  • prds/ — Product Requirements Documents (pending Confluence snapshot).
  • rfcs/ — Technical design proposals (RFCs) + their task breakdowns.
  • tests/ — Acceptance test specs tracing back to PRD acceptance criteria.
  • delivery/ — TPM program-management docs (timeline, status, decisions) — not yet created.

Scope Changes

Engineering surfaces this initiative touches, aggregated across its RFCs/PRDs.

  • Backendhub_core branding schema (branding_configs, tenant_domains, branding_assets), tenant resolver + Redis cache, payload entity/builder, feature flag; the public GET /branding endpoint in hub_service.
  • FrontendapplyBranding composable + --mp-colors-* injection in hub-chat / crm-fe-v3; completing the Pixel3 data-panda-theme=next rollout on hub-chat (prerequisite for full component theming).