Tenant Branding
Tenant Branding is the enterprise white-label configuration for the Bizaldo platform. A tenant sets its shared identity once in Admin, and supported applications request the saved branding when they load. It is separate from the logo and colours configured for an individual company's public order or booking page.
Tenant Branding is available to a tenant's Super Admin in an enterprise deployment. In cloud administration, a platform administrator manages branding for the relevant license instead.
Set your tenant brand in Admin
- Sign in to the tenant's Admin panel as a Admin.
- Open Settings → Branding.
- Set the app name, Android package identifier, default language, API base URL, and update-check URL.
- Upload the tenant icon and, when needed, a splash image.
- Set the primary and secondary brand colours.
- Select Save.
Saving sends the branding record to the license service. The tenant backend immediately refreshes its local cache after a successful save, so supported applications can receive the new version without waiting for the scheduled license verification cycle.
What happens after you save
The saved tenant name, logo, theme, language, and version are published through the backend's public branding configuration. Supported applications load this configuration, apply the name, logo, colours, page title, favicon, and theme colour, then refresh it on later visits. The asset version changes with each save, which prevents an older logo or theme from remaining in the browser cache.
What is shared
The backend publishes an unauthenticated, versioned branding payload at GET /api/config/branding. It includes the company name, logo URL, theme URL, default language, and version. The theme URL resolves the primary and secondary colours.
The version is appended to the logo and theme asset URLs. This causes clients to request updated assets after a branding change instead of continuing to use an older cached logo or theme.
If the service has no cached tenant branding, or a client cannot load it, the client falls back to its built-in Bizaldo identity. The backend cache is persisted, so the public endpoint can continue serving the last valid branding configuration after a backend restart or a temporary license-service outage.
Where the branding appears today
Where the branding appears today
| Surface | Current behavior |
|---|---|
| Admin panel | In enterprise builds, applies the company name, logo, favicon, browser/PWA title, metadata, and primary/secondary CSS theme values. It loads branding on the server for the first paint, then refreshes it in the browser. |
| Order Page | Applies the company name, logo, favicon, browser title, theme-colour metadata, and runtime primary/secondary CSS variables. It loads server-side and refreshes on the client, with local storage as an offline fallback. |
| Kitchen (KDS) | Consumes the runtime branding endpoint. Applies the company name, app title, logo, and theme colours from branding rather than Bizaldo packaged defaults. |
| Tablet/POS | Consumes the runtime branding endpoint. Applies the company name, POS and customer-display titles, logo asset, and theme colours from branding rather than Bizaldo packaged defaults. |
| TV display | TV links provide the customer-facing order-status screen, but the current repository has no runtime-branding consumer for that surface. It should be treated as Bizaldo-branded until the TV application adds the public branding fetch. |
So the tenant setup flow is complete for the Admin panel and Order Page: save in Admin, then reload the web application to see the new brand. The current Kitchen, Tablet/POS, and TV clients do not yet load the public branding configuration, so they keep their packaged Bizaldo identity. They require a client implementation change before a tenant save can appear there too.
How supported web apps apply it
- The app requests the backend's public branding configuration.
- It reads the hosted theme JSON to obtain the primary and secondary colours.
- It injects CSS variables and updates browser chrome: title, favicon, Apple touch icon, and theme colour.
- It stores the most recent valid payload locally, then refreshes it without using HTTP cache on later visits.
The Admin panel applies this only in an enterprise build. The Order Page's runtime-branding implementation also checks its enterprise build mode. Cloud shells retain the Bizaldo identity even though platform administrators can maintain branding records for licenses.
Verify a tenant branding change
After saving, use the following quick check:
- Reload the Admin panel and confirm the header/login logo, primary colour, browser title, and favicon.
- Open the Order Page in a new private/incognito window and confirm its logo, page title, favicon, and primary/secondary accents.
- Check the Kitchen, Tablet/POS, and TV display separately. Their existing Bizaldo appearance is the current expected behavior, not a failed sync.
- If a supported web app still shows the old logo, do a hard refresh or open a private window. Confirm that the saved branding version increased and that the uploaded assets are reachable from the client.
Implementation note for native and TV apps
To make Kitchen, Tablet/POS, or the TV display white-label aware, each client needs to fetch the same public endpoint before rendering its shell, read the theme JSON, apply the logo/name/colours to its native theme and title, and cache the last valid version for offline startup. This is a client implementation change; it is not achieved by adding more fields in the Admin form.