Brand & Theme

Docs-side brand tokens, naming rules, and Mintlify theme boundaries.

This page is the docs-site companion to the broader Zentra design system. The docs should feel like the same product family as the marketing site: precise, technical, low-hype, and built around reviewed public contracts.

Canonical Design Source

The current source of truth for Zentra web design is web/design/. Use it before changing docs theme, web app, or console styling.

• web/design/brand.md defines positioning, voice, palette, typography tone, imagery, and logo rules.
• web/design/tokens.md defines typography, spacing, radius, color, elevation, motion, and literal-value boundaries.
• web/design/interface.md defines marketing, developer, product-proof, and console interface behavior.
• web/design/console.md defines the stricter dense-console application of the same brand system.

Older files such as web/zentra_brand_guidelines.md, web/zentra_design_system_foundations.md, and web/console/zentra_platform_interface_bible.md are compatibility pointers. Do not add new design decisions there.

Public Naming

Use these names in external docs:

• Zentra for the company and product family.
• Zentra Developer Docs or Zentra Docs for this Mintlify site.
• API Reference for the endpoint section inside the docs.
• Financial infrastructure control plane for the public category.
• Reviewed public API surface when describing what is safe to treat as a contract.
• Optional rail add-on for capabilities that are enabled per tenant, such as virtual accounts, cards, payments, identity, or billpay.

Avoid using BaaS as the public category. It can appear only when quoting legacy/internal source material or when a runtime contract still uses that term.

Canonical URL

Use https://docs.usezentra.com as the canonical public docs URL. The older hosted Mintlify URL is a deployment detail and should not be introduced into new docs content.

Treat app, console, service, and SDK references as a separate URL migration slice after the active docs preview and deploy path pass.

Logo Assets

The docs use the same production mark geometry as the marketing site. Until the final horizontal SVG wordmark is available, the docs logo follows the interim wordmark rule from the web design system: production mark geometry plus text-rendered Zentra.

Docs logo files:

• logo/light.svg for light documentation surfaces.
• logo/dark.svg for dark documentation surfaces.
• favicon.svg for browser tabs and compact previews. It uses the brand-blue compact mark so the icon remains legible at tab size.

Do not redraw the mark, add effects, rotate it, stretch it, or recolor it outside the approved brand palette.

Theme Tokens

Mintlify needs literal hex values in docs.json, so that file is an allowed token boundary. Page content should not hardcode colors or inline style objects.

Token	Value	Usage
Primary	#2563FF	Links, active states, CTA emphasis
Light accent	#AFC8FF	Dark-mode hover and anchor gradients
Steel	#5770A0	Secondary brand support
Paper	#F5F4F0	Light document surfaces
Border	#C9CFD8	Light mode structural lines
Graphite	#2A2E35	Dark borders and raised surfaces
Ink	#14161A	Dark code surfaces
Black	#0A0A0B	Deep background and brand black

Literal Value Policy

Literal color values are allowed only in:

• docs.json, because Mintlify requires theme values there.
• global.css token declarations, where docs-specific CSS variables are defined.
• Code examples where the color is part of the example itself.
• Mermaid diagrams when the diagram language requires inline styling.

In MDX content, prefer Mintlify components without inline style objects. Let docs.json and global.css control visual treatment.

Radius Policy

Do not override Mintlify component radii inside MDX content. If a custom docs surface needs a radius, use the shared docs CSS tokens:

• 8px for compact chips or generated docs affordances.
• 12px for custom controls.
• 16px for cards, callouts, and code blocks.

Most page content should rely on Mintlify’s native cards, callouts, code blocks, and tabs instead of custom HTML buttons.

Typography Policy

Docs typography follows the web token direction:

• Use Satoshi for docs navigation, controls, body copy, and technical content.
• Keep heading and body tracking natural. Do not use negative letter spacing as a polish shortcut.
• Use uppercase tracking only for metadata, table headers, generated field labels, and compact technical markers where it improves scanning.
• Use tabular figures for money, IDs, counters, and code-adjacent data.