If you build communities for clients, borrowed branding is a problem. A client pays you to deliver their community, then sees a Powered by Jetonomy footer, a plugin logo in the navigation, and plugin-branded emails landing in their members’ inboxes. That undercuts the work. The same problem hits SaaS products embedding community features under their own name. White Label solves it by stripping Jetonomy branding from every place it appears and replacing it with the client’s identity.
This guide walks the whole job as an agency would run it: turn the extension on, rebrand the three surfaces that matter, understand the two logo settings so you set the right one for the right place, and hand over a community that reads as the client’s own product start to finish. White Label is a Jetonomy Pro feature, so the client’s site needs both the free plugin and Pro active.
Turn on White Label and find the Branding panel
White Label ships as a Pro extension, so it is off until you enable it. In the client’s WordPress admin, go to Jetonomy, then Extensions, find White Label, and click Enable. A Branding tab appears under Jetonomy, then Settings. Everything in this guide is controlled from that one panel, which keeps the whole rebrand in a single place you can walk a client through or document in a handover note.
One version note worth checking before you start. On Jetonomy 1.4.1 and newer, every Branding setting applies on every surface and every send. On older versions the settings saved but did not always take effect. Update both the free and Pro plugins together so all of the branding actually applies, then start configuring.
Rebrand the frontend
The frontend is what the client’s members see, so start here. In Jetonomy, then Settings, then Branding, you control three things.
First, remove the Powered by Jetonomy footer. It is shown by default; turn it off so the community carries no attribution link. If the client wants their own line in its place, set the footer text to their wording.
Second, set the logo. Upload the client’s logo, an SVG or PNG up to 400 by 100 pixels, to replace the Jetonomy logo in the community navigation bar. Leave the logo field blank if the client would rather show no logo at all in the nav. This is the header logo, and it is the image members see at the top of every page.
Third, inject custom CSS. The Branding panel has a custom CSS field that loads on every community page. The important detail for an agency is that it loads after Jetonomy’s own stylesheet, so your rules always win. That means you can apply the client’s brand colours and spacing without editing or forking their theme, which keeps the handover clean and survives theme updates.
Set the accent colour and understand the two logos
Two settings carry most of the brand identity, and getting them right is what separates a polished handover from a half-done one.
The global accent colour is a single override that recolours the Pro-rebranded surfaces in one place, including the email accents. Set the client’s brand colour here and it stays consistent from the community pages through to the notifications, without you hunting for individual colour values.
The two logo settings are deliberately separate, and agencies trip on this if they only set one. header_logo_url is the logo actually displayed in the community header, the image members see at the top of every page. logo_url is the fallback and Open Graph logo, used for social share cards and anywhere a logo is needed but no header logo is set. Keep logo_url set even when you customise the header separately, because it is what shows when the client’s community gets shared on social. The two are often different sizes and aspect ratios, a wide nav logo versus a square-ish share card, so treat them as two jobs and set both.
Rebrand the admin and the emails
Branding that stops at the frontend still leaks in two places the client will notice: the admin sidebar their team works in, and the emails their members receive.
For the admin, go to Branding, then Admin Menu. By default the menu item reads Jetonomy with the Jetonomy logo icon. Change the menu label to whatever fits the client, for example Community, Forum, or their product name. Set the menu icon to any Dashicons class, such as dashicons-groups, or leave it blank for the default. The label change carries through to the browser window title on every Jetonomy admin page, so even the tab reads as the client’s, not the plugin’s.
For email, go to Branding, then Email. Set the from name that appears on transactional emails and digests; it defaults to the site name, so change it to the client’s brand. Replace the default Jetonomy email footer with the client’s own text or HTML. And upload a logo to show at the top of notification emails. Combined with the accent colour, this makes every notification a member receives look like it came from the client, not from a plugin they have never heard of.
Automate it across client sites over REST
If you run more than one client community, you will not want to click through the Branding panel by hand every time. White Label exposes its settings over the REST API under the jetonomy/v1 namespace: a GET on /settings/white-label reads the current configuration and a PATCH saves it. Both routes require the manage_options capability, so only an administrator token can read or change branding. That lets an agency script a house baseline, apply a client’s logos, accent, and footer as part of a provisioning step, and keep every site consistent without repeating the manual work.
Extend the brand to a mobile app
The rebrand does not have to stop at the browser. On Pro, the Jetonomy mobile app can ship white-labelled too, carrying the client’s own name, icon, and colours rather than Jetonomy’s. So the identity you set for the web community, the logo, the accent, the tone, can extend to a native app the client publishes under their own name. For agencies, that turns a web community deliverable into a fuller branded product without building an app from scratch.
Hand it over
Done properly, white-labelling a Jetonomy community is a short, contained job: enable the extension, clear the frontend branding and set the client’s logo and CSS, set the accent and both logos, rebrand the admin menu and the emails, and script it over REST if you run several sites. The client gets a community that reads as their own on every page, in every menu, and in every inbox. See exactly what each tier includes on the pricing page, read the White-label feature overview for the capability summary, and if a client needs branding that goes beyond these settings, custom development can take it further.