Why one theme per workspace
Every visual property a block exposes — its background color, its corner radius, its title font size — resolves through theme tokens rather than hard-coded values. Change a token and every page in the workspace picks up the new value on the next render. You never edit individual page documents to rebrand the site. Whencolors.primary changes, the Hero on the landing page, the Cta on the pricing page, and the NavShell accent on the dashboard all update — no page edits required.
Token categories
A theme document organizes tokens into broad categories. To see the live token set for your workspace, fetch the theme document — it contains every token name and current value.Reading the theme
get-theme.sh
Editing the theme
Apply changes with the same RFC 6902 JSON Patch model used for pages. Patch one token or many in a single call.patch-theme.sh
test guards. The semantics are identical.
Publishing the theme
publish-theme.sh
How blocks consume tokens
A block declares which token each of its visual properties should resolve to, and the runtime substitutes the current value at render time. A Hero’s background pulls from a surface color token. A Cta button’s color pulls fromcolors.primary. A FeaturesGrid card’s corner radius pulls from a radius token. The block document does not name a hex code or a pixel value — only the token.
The benefit shows up at rebrand time. Switching a workspace from violet to teal is a single replace on /colors/primary. The eight presentational blocks and the four data-bound blocks all pick it up — no page patches, no migrations.
Per-instance overrides
For one-off adjustments on a single block instance, every block accepts theclass_overrides common prop. Overrides layer on top of the resolved theme values and affect only the instance they’re set on.
See common props on the PageBlocks overview.