Tokens (DTCG)
Design tokens as structured DTCG data, from Figma to compiled output to consumption.
Design tokens are Handoff's foundation-layer data: colors, typography, effects, spacing, radius, and grid values, extracted from Figma and/or hand-authored, normalized into the DTCG 2025.10 format, and compiled to whatever a consuming stack needs. See Workspace → Token pipeline for the full Figma → DTCG → dist walkthrough this page only summarizes.
Shape
Two tables carry token data, at two different points in the pipeline:
handoff_tokens_snapshot: the raw Figma export as fetched (localStyles.{color, typography, effect}), one JSONpayloadper push. This is the input the rest of the pipeline builds on, not what pages read from.handoff_registry_dtcg: the compiled output a workspace'stokens:buildproduces, pushed as one singleton row:manifest(the DTCG manifest),css/scss/tailwind(the compiled dist text),dtcg(alias-resolved JSON), plusbrands, axis-aware token trees keyed by brand name (and scheme, for multi-axis projects), see Registry → Singleton config rows.
Primitive vs. semantic tiers, and multi-axis (brand × scheme) resolution, are pipeline concepts covered in depth at Workspace → Token pipeline, this page is about where the result surfaces, not how it's produced.
Hand-authored tokens aren't overwritten
Some categories, spacing is the standing example, are hand-authored rather than
Figma-extracted. The build step discovers existing hand-authored files and merges them into
the manifest without clobbering them on the next fetch. See
Token pipeline → Build.
Three surfaces
| Surface | Where |
|---|---|
| UI | Foundation pages — /foundations/colors, /typography, /spacing, /border-radius, /effects, /elevation, /grid, /motion — each rendering a visual preview plus TokenOutputTabs (copy/download CSS/SCSS/Tailwind/DTCG) and a ProvenanceBadge (sync source, last-synced time). See Registry → Stakeholder-facing UI routes. |
| REST | POST/GET /api/registry/tokens (raw Figma snapshot) and POST/GET /api/registry/dtcg (+ /download) for the compiled manifest/dist, see API → /api/registry. |
| MCP | handoff_get_tokens — foundation tokens slimmed for context use, multi-axis aware (advertises available axes; pass brand/scheme for an axis-resolved result). handoff_export_design_md bundles a token brief into the exported DESIGN.md. See MCP → Tool catalog § Tokens. |
Both REST reads are public (no auth), tokens are foundation-level, non-sensitive data every
stakeholder needs to see, the same reasoning behind GET /api/registry/config being public (see
API → /api/registry → public read).