Skip to main content
Wildo.ai Coming soon

Email

Carry your visual identity into email

Email templates receive shared colors, typography and spacing values. Components can use those values to keep account messages visually related to the product.

Email components apply shared brand colors and typography to their layout.

Carry your visual identity into email

Email templates receive shared colors, typography and spacing values. Components can use those values to keep account messages visually related to the product.

Your template still decides where each value is used.

Example — Keep the action button recognizable

A password-reset button uses the same supplied email-brand palette as invitation and account-update messages.

For engineers

Author the values in backend configuration

Application example for the email section of backend-api/src/saas-config.backend.ts, using the fields accepted by EmailBrandTokens_ConfigSchema. Keep the other backend settings; replace the illustrative sender with your configured sending identity.

email: {
  from: 'noreply@example.com',
  brandTokens: {
    primaryColor: '#245b8a',
    secondaryColor: '#60758a',
    fontFamily: 'Arial, Helvetica, sans-serif',
  },
},

These inputs override the corresponding email defaults. fontFamily also supplies headingFontFamily; other palette values retain their defaults. The token builder converts supported color inputs to email-style values. It does not derive an entire theme from the primary color or load the application’s web CSS.

Read the email brand object in components

EmailBackendService builds EmailBrandTokens from the backend email configuration and passes them to the subject/body render functions. The layout consumes these values explicitly:

Selected from EmailLayout.tsx; surrounding module configuration is omitted.

      <Body style={{
        backgroundColor: brand.mutedColor,
        fontFamily: brand.fontFamily,
        margin: 0,
        padding: '40px 0',
      }}>
        <Container style={{
          maxWidth: '600px',
          margin: '0 auto',
          backgroundColor: brand.backgroundColor,
          border: `1px solid ${brand.borderColor}`,
          borderRadius: brand.borderRadius,
        }}>
          <EmailHeader brand={brand} appName={appName} logoUrl={logoUrl} />
          <Section style={{ padding: '32px' }}>
            {children}
          </Section>
          <Section style={{ padding: '0 32px 32px 32px' }}>
            <EmailFooter brand={brand} appName={appName} supportEmail={supportEmail} />
          </Section>
        </Container>
      </Body>

The layout above uses the shared font and neutral palette. Components such as PrimaryButton use brand.primaryColor for the action. Preview both together after changing the configuration: only components that read a changed token should change.

Supply the logo through context

Pass the resolved primaryScopeContext.logoUrl to the shared header. It is an absolute email-appropriate asset URL resolved for the send context. Colors and fonts belong to brand; logo identity belongs to context. Keeping these separate lets the sender provide the appropriate asset without hard-coding it into every template.

Companion preview and test-send share the configured absolute logo resolution and support the same context overrides. Use an explicit context override to inspect another identity; choosing a recipient does not load that recipient’s organization.

Preview the generated HTML, including long translations and missing optional logos. A component that never reads a token will not change merely because that token was configured.

Building a B2B product or an internal tool?

Wildo is not self-service yet. Tell us what you have in mind and we will say plainly whether it fits, and what happens next.