White-Label & Branding
Iron supports per-org brand chrome so a subaccount can present its own product name, logos, favicon, and accent color. Branding is resolved through the org hierarchy: an org’s own brand → its parent agency’s brand → the product default.
What’s brandable
Section titled “What’s brandable”The stored branding for an org can include:
product_name— the displayed product name.logo_url/logo_url_light— logos (dark and light variants).favicon— the browser favicon.accent— the accent color used in the brand chrome.
Endpoints
Section titled “Endpoints”| Method | Path | Description |
|---|---|---|
GET |
/api/v1/orgs/{org_id}/branding |
Read this org’s stored branding plus the fully-resolved effective brand (operator). |
PUT |
/api/v1/orgs/{org_id}/branding |
Set this org’s branding. |
GET |
/api/v1/public/branding/resolve |
Resolve the effective brand for a host / org without auth (used to brand login and public surfaces). |
The effective brand is the org’s own brand if set, otherwise its parent agency’s, otherwise the product default — so a client subaccount inherits its agency’s brand unless it overrides.
Current product posture
Section titled “Current product posture”Iron is the agency’s operating system plus custom-fit client portals — not a self-serve white-label SaaS. The branding system exists and resolves through the hierarchy, but the current product decision keeps the chrome as Local Lead Legend (no separate product brand, logos dropped). The per-org branding capability remains available for when a client portal should carry the client’s own name.