Branding & white-label
Your brand once — applied to every product you build and every email your customers receive.
Brand kit
The default look for new products.
SVG or PNG · used in app headers and system email
Primary
Ink
Success
Surface
- Headings
- Space Grotesk
- Body
- Inter
Email sender identity
What your customers see in their inbox.
- From name
- GoClaw
- From address
- [email protected]
- Domain status
- Verification pending
Add these DNS records at your domain host:
TXT goclaw.io → v=spf1 include:mail.buildwithhq.com ~all
Until verification completes, email sends from the platform domain — an unverified address is never used.
How branding flows
The same layering used for pages and AI packs.
Logo, colors, and type — the default identity for everything you build.
Every new SaaS starts looking like your brand, not like a template.
A product with its own look stores only the pieces it changed.
Change the kit and un-forked pieces update everywhere — customizations are never overwritten.
Set your logo, colors, and type once, and everything you build starts on-brand — including the emails your products send to your customers, from your own domain once it’s verified.
Defaults, not decrees: products that customize their look keep those customizations forever. Updating the kit changes only the pieces a product never touched.
Behind this page/branding · CanManageAccount
Retrieve
sp_Builder_GetBrandKit — one call: kit fields (kitExists, logo URLs, designTokens, basedOnThemeKey via syn_TemplateThemes, brandVersion, base64 rowVersion) plus the nested senderDomains[] array with computed dkimRecordName. Migration 2026-08-01_02_customer_branding.sql.Save
sp_Builder_UpsertBrandKit (insert-or-update; @ExpectedRowVersion BINARY(8) base64 round-trip; conflict 55080 → 409; bumps BrandVersion; audited) · sp_Builder_UpsertSenderDomain (DKIM keypair generated app-tier, public key only to SQL; dup 55084 → 409) · sp_Builder_SetDefaultSenderDomain (verified-only, 55086 → 422) · sp_Builder_RemoveSenderDomain (soft). Verification state is written ONLY by the worker via sp_Communication_RecordSenderDomainVerification. Full endpoint + worker contract: docs/HANDOFF_branding.md.Success
- Permission enforced in-proc (CanManageAccount, 55081 → 403); identity params server-injected.
- Layering: kit = account base; per-app SaasAppTheme forks COALESCE down; seed-time propagation is a separate tenant-plane change (noted seam).
- Unverified domains can never be the default sender — mailer falls back to the platform sender.
- Remaining build items: sender_domain_verifier.py worker; theme-picker list proc over syn_TemplateThemes.
CLI handoff
Implement this scaffold from the structured contract, then remove hard-coded preview rows. The source of truth is CLI Handoff and admin-cli-manifest.json.
Server-inject identity and scope values; never trust browser-supplied account, app, tenant, user, entitlement, price, or permission identifiers. Preserve the loading, empty, forbidden, failed, retrying, and completed states shown by the preview.