White-labeling

An agency or a reseller can run Artbucket as its own product. Each organization sets its brand once, and it shows everywhere a person or a guest sees the product: the app, the sign-in screen, page titles and the browser tab, share links, portals, and every email.

Branding

Settings, Organization, Branding, or PATCH /api/v1/settings/branding:


Name	What the product is called: page titles, sign-in, email subjects
Tagline	Under the name on the sign-in screen
Logo	An approved image of the library: the sidebar, sign-in, share links, email
Icon	An approved square image: the browser tab
Accent	Buttons, links, focus rings, in light and dark
Follow a brand	The accent is a brand’s primary color as last released, so each release recolors the app
Email footer	A line at the foot of every email

Images are assets of the organization’s own library, and show only while they stay approved: archive the old logo and it leaves the product with it.

With a name but no logo, the sidebar shows the name’s initial on the accent. Following a brand and nothing else keeps the product’s own name and marks, in that brand’s color: a team running its own brand on Artbucket sees it in the app the moment it releases. With nothing set, the product looks like itself.

Where limits switch branding off, public and password portals also carry a small “Powered by Artbucket” link in their footer; members’ portals don’t. With branding on, as on a server without limits, they carry nothing of it.

Customized, the sign-in page is the card alone, centred: the panel beside it on wide screens is the product’s own, shown only when nothing is set.

For the whole server

BRAND_NAME, BRAND_TAGLINE and BRAND_ACCENT brand every organization that hasn’t set its own, property by property. A reseller sets them once.

Who sees which brand

On an organization’s own domain: that organization’s.
Signed in, or with an API key: the organization of the project you’re in.
A share link or a portal: the organization it belongs to, whoever opens it.
Anyone else at APP_URL: the only organization’s, when the server has one, else the server’s (BRAND_*).

A portal’s own logo and accent win over its organization’s; anything it leaves empty comes from the organization.

A domain for the app

Settings, Organization, Domains, or POST /api/v1/domains:

Add the domain, e.g. assets.acme.com.
At your DNS host, point it at the server (a CNAME to its host name, shown too when DOMAIN_TARGET is set) and add the TXT record shown, _artbucket-challenge.assets.acme.com.
Check now.

A domain added but not verified within 7 days no longer holds the name: anyone else can then add it.

Keep the TXT record after that. The server looks at verified domains’ records again every few hours, and one whose record is gone at every look for 7 days is unverified: it stops serving, and anyone else who proves it may take it. Putting the record back and Check now verifies it again. A lookup that fails (a DNS server down, a timeout) counts for nothing either way.

Once verified, the whole app answers there in the organization’s brand. People sign in there, and invitations, share links and portal links in email point there. It needs a certificate: see TLS for portals, which covers app domains the same way, since GET /api/v1/domains/check answers for both.

Email

Every message renders in the organization’s brand: its name in the subject and text, its logo on top, its accent on the button, its footer below. The sender name and address are the organization’s Email setting: send from your own domain there, e.g. Acme Assets <assets@acme.com>, once your provider has verified it.

What stays

What developers see keeps its name: the API reference, the MCP server’s name and the CLI. Agents connect to artbucket whatever the brand.