Theming and Localization
What of the embedded surfaces you can brand today, and what is still fixed - styling, copy, language, and the URLs and emails your customers see.
Coming soon
White-labelling has two halves. The placement half is available today: your product chrome wraps the embedded surfaces, and your customer never navigates to a ByteChef URL. The appearance half is partly configurable - colors, font, corner radius and light or dark mode on some surfaces - and this page is the honest inventory of what you can change and what is fixed.
What you control today
- Where the surfaces sit. The Connect dialog opens from your own UI, and the Automation Hub, Integration Marketplace and workflow builder render in an iframe you position and size. Your layout, your navigation, your typography around them.
- The look of the Automation Hub and Integration Marketplace. Both components take a
themeprop. It setsmode('dark'or'light'),primaryColor,fontFamily,borderRadius, the surface colors (surfaceColor,cardColor,activeBorderColor,enableColor,disableColor,onAccentColor,segmentColor) andcssVariables, a map of any CSS custom properties starting with--. Colors that the browser does not recognize, and aborderRadiusthat is not apx,rem,emor%length, are ignored. The hub's theme also applies to the workflow builder the hub opens. See Theming on the Automation Hub page. - The Connect and activation dialogs.
useConnectDialoganduseActivationDialogtakemode: 'dark' | 'light'(default'light') and read--bytechef-dialog-*CSS variables. See Styling the dialogs. The Integration Marketplace passes itstheme.modeto the dialog it opens. See Displaying the Connect Dialog. - What is in the catalog.
includeComponentsrestricts the workflow builder, standalone or opened from the Automation Hub, to the components you choose, and permission expressions narrow what each connected user is offered. Your customers do not see the full ByteChef catalog unless you want them to. - Which workflows exist. You author the templates; customers configure them rather than starting from a blank canvas.
Styling the dialogs
The Connect dialog and the activation dialog render in your page, not in an iframe, and read these CSS variables. Set them on :root or any ancestor of the dialog.
| Variable | Used for |
|---|---|
--bytechef-dialog-surface | Dialog background. |
--bytechef-dialog-surface-raised | Raised areas inside the dialog. |
--bytechef-dialog-border | Borders. |
--bytechef-dialog-text | Text. |
--bytechef-dialog-text-muted | Secondary text. |
--bytechef-dialog-hover | Hover backgrounds. |
--bytechef-dialog-primary | Primary buttons and accents. |
--bytechef-dialog-primary-hover | Primary button hover. |
--bytechef-dialog-primary-foreground | Text on primary buttons. |
A variable you do not set falls back to a built-in color. mode: 'dark' switches the surface, border, text and hover fallbacks to a dark palette.
The Automation Hub maps its theme onto these variables, so the dialogs it opens match the hub.
What is fixed
The standalone EmbeddedWorkflowBuilder component has no theme prop - it takes only the host, the environment, the token, the workflow and its connection and component options, and renders ByteChef's default light appearance. To theme the builder, open it from the Automation Hub. No surface accepts copy or a locale.
| Surface | Status |
|---|---|
| Colors, fonts, radius | Configurable on the Automation Hub and Integration Marketplace through theme, and on the Connect and activation dialogs through mode and the --bytechef-dialog-* variables. Fixed on the standalone workflow builder. |
| Language | English only. No locale option, and no translation files to supply. |
| Copy and labels | Fixed, including validation messages inside the Connect dialog. |
| Engine error messages | Fixed and in English. Surfaced as-is in execution history. |
| Webhook URLs | Served from your ByteChef host, not a domain of yours. |
| Customer-facing email | Not sent from your domain or with your templates. |
| Documentation links | Component help points at ByteChef docs, not your help center. |
What this means in practice
For most embedded products the gap is smaller than it looks: the surfaces are modal or iframed inside your app, so the visual seam is a panel rather than a page. The two that tend to matter first are language, if you sell outside English-speaking markets, and webhook URLs, if your customers paste them into a third-party system and would see a ByteChef host.
If either is a requirement rather than a preference, raise it before you build - they are roadmap items, not configuration you have missed.
Related
- White-Label Execution - what your customers experience, and the tenant isolation behind it.
- Component Kit - the tools API, where the names and descriptions your agent surfaces come from the components themselves rather than from your copy.
How is this guide?
Last updated on