Skip to main content

Branding API

Resolves the effective branding (logo, colors, brand name, support email) that should apply for the calling org or, when called by an unauthenticated subaccount surface, for a custom-domain host. Base path: /api/v1/branding Authentication: API key (X-API-Key) or session JWT. An unauthenticated caller may pass X-Tenant-Host: <custom-domain> to resolve the branding of the tenant that owns that domain — this is how a white-labelled sign-in page renders before a session exists (at a lower, IP-keyed rate limit). This endpoint is hot — the Next.js dashboard middleware polls it on every authenticated render. Responses carry Cache-Control: private, max-age=60, so each client caches for ~60 s.

Get effective branding

GET /api/v1/branding/effective The resolver merges the calling org’s branding with its reseller parent chain: any field the org has not set for itself is inherited from the parent, and unset-on-every-side fields come back null (the platform default theme applies). If a database blip makes branding unresolvable, the endpoint still returns 200 with a fully-nulled neutral shape so the dashboard shell never fails to render.
inherited_from_organization_id names the parent org a value came from; inherits_from_parent is true when the calling org takes the parent’s branding wholesale (subaccounts with inherit_branding_from_parent enabled). Both fields are resolver diagnostics — keys to know where the value came from, not a branching condition for your own rendering.

From the SDKs

The Node SDK reads the calling org’s branding with its own credentials — useful for server-side rendering of white-labelled portals:

Client caching

The responses carry Cache-Control: private, max-age=60. Cache the resolved branding per host (or per org) for up to that 60-second window instead of re-fetching on every render; fall back to your default theme when branding can’t be resolved, the same fallback the endpoint itself uses:

See also