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.rfcs/rfc-unified-branding-service-be.md— backend RFC for thehub_corebranding store, resolver, cache, and payload contract (theGET /brandingHTTP endpoint and FE consumers are cross-repo / cross-squad).rfcs/rfc-unified-branding-service-be.task-breakdown.md— ordered, estimated task breakdown for thehub_corein-repo scope (~14.5 dev-days, incl. whitelabeling the customer-email header logo).
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.
- Backend —
hub_corebranding schema (branding_configs,tenant_domains,branding_assets), tenant resolver + Redis cache, payload entity/builder, feature flag; the publicGET /brandingendpoint inhub_service. - Frontend —
applyBrandingcomposable +--mp-colors-*injection inhub-chat/crm-fe-v3; completing the Pixel3data-panda-theme=nextrollout onhub-chat(prerequisite for full component theming).