Brand settings

What it is

Every Brand has its own settings screen. Open it from the gear on the Brand: beside the Brand switcher at the top of the sidebar, on each Brand’s card on Overview (and Brand settings in its ⋯ menu), and Brand settings in its panel in the Command Center; or from the command palette (⌘K, “Brand settings: Acme”). The Brand picker at the top right switches to another Brand and keeps the page you’re on. The Brand’s mark and name sit in the header, where a Brand Admin can change them in place.

It has a page for each part: General (with Delete this Brand in red at its foot, for the workspace Owner), People & approvals (People & groups beside Approvals), Release paths and Integrations. On a wide screen the pages are listed on the left; on a laptop, tablet or phone they are a row of buttons above the page (on a phone, swipe along it). The page you’re on is highlighted, and [ and ] go to the previous or next page. Old links to a part of Brand settings, and to Settings › Brand settings, Webhooks and Penpot, open its page.

Viewer

Opens the page and reads it, except the webhooks list.

Editor

Makes and revokes the share link, connects Penpot, and suggests release paths.

Reviewer

Lets people in from the share link, and suggests release paths.

Admin

Renames the Brand, changes its mark, its sizes and what it inherits from, manages its webhooks and its Community listing, and decides its release paths.

Owner

The workspace Owner can delete the Brand, as long as the workspace keeps another.

General

• Rename and Change mark (Brand Admins). Everyone in the workspace sees the change straight away; links and exports keep working.
• Inherits from: build this Brand on another Brand in the same workspace. It inherits the parent’s token sets (and its parent’s), and its own sets override them. Good for sub-brands that share most tokens. It applies from the next release submitted.
• Create share link (Editors): a link for people outside the workspace, such as a client, to ask to see the tokens. It’s shown once, so copy it straight away. Revoke link stops it for everyone. Their Access requests wait under it: Let them view, View and comment (Admins) or Deny. They show in the Command Center too.
• Share with community, then Update community listing or Remove from community (Brand Admins). See Community.
• Brand Book (Brand Admins choose): who can read the Brand’s docs site, built from each release: off, anyone with the link, public (its Community listing) or workspace only (Team). Copy link, Make a new link and Turn off are right there; Open the Book page shows the book. See Brand Book.
• Delete this Brand, at the foot of General in red, for the workspace Owner. Press and hold Hold to delete (or hold Space or Enter on it) for 1.5 seconds; letting go early cancels. Or choose type its name instead to confirm by typing the name. Its themes, token sets, releases and components go too. A workspace keeps at least one Brand.

Sizes

Sizes, on General, is how sizes work in this Brand: set it once and forget it. Brand Admins and Owners change it; everyone else can read it. It never changes a stored value.

• Root size: what 1rem is in pixels (8 to 32; browsers use 16). rem, and an em with nothing around it, convert with it, in previews, the iOS and Android files, Figma and Penpot.
• One row per kind of size: font sizes, line heights, letter spacing, spacing, corner radius, border widths, shadow sizes, layout sizes and other sizes, each with an example token. A token’s kind comes from its name (font.size.body is a font size, space.md spacing) or, inside a type style, shadow or border, from its field.
• Units it may use: tick the units that kind can be written in. The defaults keep % out of font sizes and keep vw, vh, vmin and vmax for layout sizes, so type stays in real sizes. An edit in a unit the kind doesn’t allow is refused with what to do; a token brought in from a tool keeps its unit and is only marked.
• Show as: As written, or converted to px, rem or pt. A 24px font size shown in rem reads 1.5rem (24px) everywhere in the Brand (Tokens, the editor, reviews and Compare) and stays 24px. %, vw, vh, vmin, vmax and ch can’t be converted exactly, so they always read as written. A number typed on its own takes the unit it’s shown in.
• Save sizes keeps your choices; Reset to Stoaken’s defaults puts every kind back (then save). If saving fails, the message says why and Try again sends the same choices.

Exports keep units as written (CSS, SCSS, Tailwind, JavaScript and the design-token JSON). The design-token JSON’s Strict DTCG option is for tools that read only the official px and rem: em and pt become rem at the root size, and %, vw, vh, vmin, vmax and ch sizes are left out and listed. iOS and Android convert rem, em and pt with the root size and leave relative sizes out with the reason; Figma gets pixels, and relative sizes stay in Stoaken with a note.

People & groups

On People & approvals: everyone who can open this Brand, with their photo, name, job title and role here. Emails aren’t shown. Groups used here lists the groups this Brand’s approval policies pick.

Roles are changed in Members by a workspace Admin, and groups in Groups. Workspace Owners and Admins work on every Brand, so a Brand with no one listed is still looked after. If the list can’t be loaded, the page says so, with Try again.

Approvals

Beside People & groups on the same page: the approval policies a release of this Brand must meet, the ones made for it and the ones for every Brand, each said in a sentence. Paused ones are marked. To change them, follow the link to Approval policies, which then shows only the policies that apply to this Brand (Show all policies lifts that).

Velocity

Velocity, on People & approvals under Approvals, lets releases a person sends from Stoaken that break nothing go live after their checks without waiting for a reviewer (see Velocity). Anything an AI agent or a tool proposes (MCP, the REST API, the CLI, the Figma plugin connected with an API key) always waits for a person. A designer who signs the Figma plugin in with Stoaken sends as themselves, so their own releases from it count as a person’s (Sign in with Stoaken). It is on by default for a new Brand and for one still below 1.0. A Brand that was already at 1.0 or later when velocity arrived starts with it off, so nothing changed for it.

Brand Admins and Owners turn it on or off with Turn velocity off or Turn velocity on; everyone else can read it. An approval policy that applies always wins, and the card says so. So does the rule that people decide on what agents and tools propose.

When the Brand first publishes 1.0.0 or later with velocity still on, the card and the release’s rollout page suggest Switch to full review, one click; Keep velocity answers it. Velocity never turns itself off.

Release paths

The Release paths page lists the places a release of this Brand has to reach: your CI, Figma, a webhook such as a Zap, Penpot, or something done by hand. Each one names who signs it off, says whether it’s Required or Optional, and how it confirms. Every release created from now on takes a copy of the approved ones, with their owners; a release already under way keeps its own.

• Suggest a release path (Editors and Reviewers) opens a three-step setup. Where does a release need to land? picks the kind of place: Code & CI (your build reports it, so it confirms itself), Design tools (Figma’s plugin reports it; Penpot is checked by a person), Automations & chat (a Zap, scenario, workflow or chat app; it lands when the tool accepts the release) or By hand (its owners press It’s live). The second step (Which tool builds it?, Which design tool? or Which tool picks it up?) lists the tools from the integration guides, with what happens on every release, what you’ll need and a link to the tool’s guide (Guide coming when it isn’t published yet); Another CI or a script and Any other address cover the rest, and By hand skips this step. Coding agents aren’t listed: they propose changes, they aren’t a place a release lands. Jira and Linear aren’t either: they only hear about a release when it’s sent for review, so add them By hand. Who signs it off? sets the name (it starts as the place and the tool, like “Web app (GitHub Actions)”; change it freely), the owners and what it’s for, beside a preview of the path and how it will land. Suggest this release path sends it: it waits, marked Waiting for a Brand Admin, and the Brand’s Admins are told in the bell. A Brand Admin’s own (Add a release path, then Add this release path) goes straight in.
• Same thing? If the Brand already has a path of the same kind with a similar name, the dialog asks. Yes, tell Sam (its first owner) tells its owners in the bell that you need it too, and suggests nothing. No, mine is different carries on. Two paths can’t share a name.
• Who signs it off: people who work on this Brand (Editors, Admins and Reviewers), or a group. A group signs off when anyone in it who works on this Brand does; a Viewer in the group can’t. The picker shows names and job titles, never emails.
• Connect your Zap now (Zapier; Connect your scenario now for Make, Connect your workflow now for n8n, Connect the address now for any other address): paste its https address. Stoaken sends it one test event straight away and keeps the address encrypted with the suggestion. When a Brand Admin approves with Connect the Zap they added, it becomes a webhook sent release.published (webhooks need the Team plan), and from then on the path lands by itself when the Zap accepts a published release. That means the Zap accepted it, not that anything deployed. Slack, Teams and Discord have their own message format, so there’s no address to paste: add their webhook in Integrations, and a Brand Admin connects it with Connect a webhook.
• Approve or Decline (Brand Admins). Approving can change who signs it off first. Declining takes an optional reason, and the suggestion moves to Declined suggestions. Releases already under way are offered a newly approved path; nothing is added to them by itself.
• Required (Brand Admins): a path starts optional. Once it has landed on a release, an Admin can make it required, from the next release on. Nothing flips by itself.
• Change owners, Connect a webhook (one of this Brand’s webhooks that is on and sent release.published), and Remove (Brand Admins). Removing is for new releases only: releases under way keep their copy, and history keeps its name.
• Still needed? Brand Admins see this on a path that hasn’t landed in the last 3 releases, or whose owners have all left or no longer work on this Brand. It changes nothing; it asks you to look.

Integrations

The Integrations page holds this Brand’s webhooks and its Penpot file, which used to have their own pages in Settings (old links and bookmarks still land here). Webhooks are for Brand Admins: anyone else sees Webhooks are managed by Brand Admins. Penpot is connected by an Editor and shown to everyone.