> ## Documentation Index
> Fetch the complete documentation index at: https://docs.artbucket.io/llms.txt
> Use this file to discover all available pages before exploring further.

# White-labeling

> Your product name, logo, colors and domain, everywhere your people and guests look.

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                             |
| 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.
With nothing set, the product looks like itself.

### 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 workspace 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`:

1. Add the domain, e.g. `assets.acme.com`.
2. At your DNS host, point it at the server (a `CNAME` to its host name) and
   add the TXT record shown, `_artbucket-challenge.assets.acme.com`.
3. **Check now**.

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](/guides/portals#tls),
which covers app domains the same way, since `GET /api/v1/domains/check`
answers for both.

<Note>
  Two things still go through `APP_URL`: single sign-on returns there after the
  provider, and password reset links point there. Both work; they just show the
  server's address.
</Note>

## 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.