> ## Documentation Index
> Fetch the complete documentation index at: https://notifizz.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Email Library — Layouts, Sections and Assets
> The reusable building blocks your emails are made of: one layout as the envelope, sections stacked inside it, assets they point at — plus the lifecycle, the brand tokens and the plan ceilings.
# The email library
An email in Notifizz is not a file you edit once and copy for the next campaign. It is a **layout** — the envelope — with an ordered stack of **sections** inside it, drawing on the images in your **assets** library. Build the blocks once; every campaign composes from them.
This page is written for the **marketing side** of the team: what the pieces are, who decides what, and what your plan caps. The parts that only a developer touches — the component contract, the save-time checks — are marked as such and kept short.
## TL;DR
* **A layout is the envelope**: header, page background, the centred frame, and the footer with the unsubscribe link. Your organisation always has exactly one **default layout**, and it is seeded for you on day one.
* **A section is a content block** inside that envelope — a heading, a paragraph, a button, an image. An email is an ordered stack of them.
* **An asset is an image** in your organisation's gallery, referenced by the layouts and sections that display it.
* **Four sections ship built in** — Text, Image, Button, Spacer — and the button already renders in your brand colour. Most organisations need a handful of custom sections on top, not dozens.
* **Every property is typed**, and each type gets its own control in the editor: an image picker, a markdown field, a colour picker, a date picker, a CTA destination.
* **Brand chrome can be marked private** — frozen to its value and hidden from whoever reuses the block, so nobody is asked about your logo again.
* **Publishing freezes a component.** Campaigns pin the version they were built against, so improving a block never rewrites an email that already shipped.
* **Layouts, sections and stored assets are capped by your plan.** The ceiling applies to new creations only — nothing you already own is ever taken away.
## The three pieces
| | What it is | Where it lives | Who usually owns it |
| ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------- | ----------------------------------------------------------------------- |
| **Layout** | The envelope around everything: page background, the centred frame, header, footer, unsubscribe link. Reserves one slot in the middle where sections are injected. | Settings → Layouts | Set up once, rarely touched |
| **Section** | A self-contained content block that drops into that slot: heading, prose, button, image, a boxed callout. Stackable and reorderable. | Settings → Sections | Marketing composes with them; a developer or the AI editor authors them |
| **Asset** | An image, stored once and reused: logo, icon, hero picture. Organised into folders. | Settings → Assets | Anyone with dashboard access |
A layout and a section are the *same kind of object* under the hood — the difference is that a layout owns the page and reserves a slot for children, and a section owns nothing but its own block. That difference is fixed at creation: **a component's kind can never change**. A section will never become a layout; make a new one instead.
## How an email is composed
```mermaid theme={null}
flowchart TB
subgraph L["Layout — the envelope, one per email"]
direction TB
H["Header — logo, brand name"]
subgraph SLOT["The slot — your sections, in order"]
direction TB
S1["Heading"]
S2["Text"]
S3["Button"]
S1 --> S2 --> S3
end
F["Footer — legal line + unsubscribe link"]
H --> S1
S3 --> F
end
```
A campaign's email step holds a subject line, a layout, and the ordered list of sections. Nothing else. Pick no layout and your organisation's default is used.
Two consequences worth internalising:
* **Sections never set their own width or side margins.** The layout owns the column, so every section lines up on the same edge no matter who wrote it. A section only controls its own vertical rhythm — the gap to its neighbours above and below.
* **Reordering is free.** Because a section is a fragment and not a whole document, moving it up or down cannot break the page.
## Properties: what changes per send, what stays fixed
Every section and layout declares its **properties** — the values it reads. They are typed, and the type decides the control the editor shows:
| Property type | Control in the editor |
| -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Image | Picker on your assets gallery, with upload |
| Rich text | Markdown field — bold, bullet lists and links actually render |
| Colour | Colour picker: swatch, hex field, on-screen eyedropper |
| CTA destination | A destination **intent** in plain words ("View the invoice"), which Notifizz resolves to a real, tracked URL at send time — see [link routes](/docs/concepts/link-routes) |
| Date, date-and-time, time | Calendar and clock pickers |
| A fixed set of choices | Dropdown |
| Number, short text, on/off | Number field, text field, toggle |
Two properties of the same block are not equal in status:
* **Public properties are content.** Headline, body copy, button label and destination, images, amounts, dates, list items — anything that changes from one campaign to the next. They stay editable by whoever composes the email.
* **Private properties are brand chrome.** Logo, brand colour, legal footer line, fixed structural styling. Marking a property private **freezes it to its value and hides it** from the composer — and from the AI. A campaign author is never re-asked about your logo, and cannot break it by accident.
Private is not a permission. It is a statement about the value: *this does not change from one email to the next*. Anything a marketer might legitimately want to tune stays public.
Default values are copied into a block **at the moment you place it** in an email. Change the component's defaults later and existing placements keep the values they were given — no silent rewrite of an email you already approved.
## What ships with every organisation
**One default layout**, created with your organisation and named *Base*: a white card on a light ground, a brand wordmark, the slot, and a compliant footer. It is ready to send as-is, and it already satisfies the unsubscribe rule below.
**Four built-in sections**, which no plan counts and nobody can delete:
| Built-in | What it already covers |
| ---------- | -------------------------------------------------------------------- |
| **Text** | Prose in markdown — bold, bullet lists, inline links, sub-headings |
| **Image** | An image at three widths (small, medium, large) |
| **Button** | A call to action that already renders in your brand colour and shape |
| **Spacer** | Vertical breathing room at three heights |
They are the reason a healthy library is small. Before anyone builds a "Paragraph" section, a "Bulleted list" section and a "Link" section, note that the built-in Text block is all three. What genuinely justifies a custom section is what markdown cannot express: a styled heading, and anything sitting on a coloured block background.
## Brand tokens
Rather than pasting your colours into every block, components reference tokens that Notifizz substitutes when the email is rendered:
| Token | Resolves to |
| --------------------- | --------------------- |
| `{{brand.primary}}` | Your primary colour |
| `{{brand.secondary}}` | Your secondary colour |
| `{{brand.logo}}` | Your logo URL |
| `{{brand.name}}` | Your brand name |
| `{{brand.radius}}` | Your corner radius |
Set them once in your brand settings and every block that uses a token follows — including the built-in button. Hard-coding a colour into a component severs that link and the block stops following a rebrand; see [brands and variables](/docs/concepts/brands-and-variables).
## The default layout, and the unsubscribe rule
**Your organisation always has exactly one default layout.** Setting another layout as the default is a *swap*, performed in one write: there is never a moment with none. Two consequences the dashboard will hold you to:
* The current default **cannot be archived**. Promote another layout first, then archive it.
* The default **cannot be cleared**, only replaced.
**A layout cannot be published without an unsubscribe link.** Exactly one footer link, whose destination is the reserved placeholder `{{notifizz:unsubscribe}}`. The wording is yours — *Unsubscribe*, *Manage my preferences*, anything. The destination is not:
* Notifizz fills it **per recipient**, so it can never point at the wrong preference page.
* It is **stripped entirely on transactional sends**, which carry no unsubscribe surface.
* A second, hard-coded unsubscribe link is refused, because it would survive that strip and mail a dead link to a real person.
This is checked when you publish, and enforced again at render. See [privacy friendly](/docs/concepts/privacy-friendly) for what happens on the other side of that link.
## Lifecycle: Editing, then Live
A component is in one of two working states, plus an archive:
| State | What it means |
| ------------ | --------------------------------------------------------------------------------------------------------------------------------------------- |
| **Editing** | Being authored. Code and default values are still changeable. A component that has never been published cannot be placed in a campaign email. |
| **Live** | Published and frozen. A campaign only ever places a published version. |
| **Archived** | Out of circulation. Restoring returns it to the state it was in before. |
**Publishing freezes the block.** It leaves the editor, and its default values can no longer be changed — an attempt to rewrite them is refused. To change something afterwards, create a **new version**: the published version is frozen as an immutable snapshot, and the head returns to *Editing* one version up, ready to edit and republish.
Meanwhile, **each placement pins the version it was composed against**. A campaign built on version 2 keeps rendering version 2 even after version 3 is published, and keeps rendering it identically a year later. Upgrading a placement is a decision, not a side effect.
Renaming a component changes its **display name** only, in any state. Its key — the identity every existing placement resolves through — never changes.
## Two checks before anything is saved
**Developer detail.** Components are authored as typed, React-based email components. If nobody on your team writes them by hand, the editor's AI chat and the [migration assistant](/docs/sdks/how-to/migrate-email-templates) do it for you, and these two checks still apply to what they produce.
Every save — by hand, by the AI editor, or by the migration assistant — passes the same two gates:
1. **A code check.** Only React and the email component library may be imported. Dynamic imports, `eval`, raw HTML injection and prototype access are refused outright. An email is rendered with your recipients' data in it; unescaped HTML in that position is not a stylistic preference.
2. **A render check, through the send path.** The component is rendered once, with nothing but its own defaults, using the very engine that renders your real emails. If it fails, the save is refused with the exact error — and the author, human or AI, can fix it immediately.
The second one exists because a preview that works proves nothing about a send that does not. A block that cannot render must never become the version a campaign resolves at delivery time.
## Assets
The gallery is one image library per organisation, organised in nested folders.
| | |
| ----------------- | ----------------------------------------------------------------------------------------------------- |
| Accepted formats | PNG, JPEG, GIF, WebP, AVIF |
| Maximum per image | 5 MB |
| SVG | **Refused on purpose** — an SVG is an active document and can carry scripts. Convert it to PNG first. |
| Archiving | Hides the image from the gallery. The bytes stay stored, and keep counting against your storage. |
| Deleting | Removes the image and **frees the storage** it occupied. |
Images attached to the editor's AI chat as visual references are stored in the same place and count the same way.
## What your plan caps
Three of the library's objects are metered as **stock** — a ceiling on what your organisation *owns*, not on what it sends:
| Resource | Counted as |
| ------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Layouts** | Non-archived layouts |
| **Sections** | Non-archived sections. Built-ins are not yours, so they never count; neither do the frozen snapshots of past versions — one component is one unit however long its version history. |
| **Assets storage** | Total megabytes stored, gallery and chat references together |
Four rules make this predictable:
* The count is **live**. Archive a section or delete an image and the capacity comes back immediately.
* Only **creation** is ever refused, with an explicit error naming the resource and its ceiling. Editing, publishing and sending are never blocked by a stock limit.
* If a plan change puts you above a ceiling, **nothing is taken away**. You keep everything; you simply cannot add until you are back under.
* Your current figures are in the **Billing & usage** view, under *Stored resources*, next to your send volumes.
## Authoring with the AI editor
Each component has its own editing conversation: describe the block you want, attach a screenshot or a reference image, and the editor writes it — typed properties, editor controls, public/private split and all. It asks a question only when the answer would change the block's shape, and it always returns a working preview in the meantime.
Each request draws **one AI credit** from your organisation's pool. When the pool is empty the editor says so and tells you when it refills.
For a whole existing template set, don't do it block by block — see [migrating your existing email templates](/docs/sdks/how-to/migrate-email-templates).
## FAQ
Because it has never been published. Only a component with a published version can be placed in a campaign email — an unpublished draft has nothing frozen to render. Publish it, and it appears.
Because each placement pins the version it was composed against, on purpose: publishing an improvement must never silently rewrite an email that is already approved and sending. Open the campaign and move the placement to the new version when you want it.
No — a component's kind is fixed at creation, and everything downstream (the slot, the unsubscribe rule, the width ownership) depends on it. Create a layout and carry the content over. Duplicating a component is one click, and the copy starts fresh in Editing.
A layout must carry exactly one footer link whose destination is the reserved unsubscribe placeholder. A hard-coded link to your own preference page does not qualify — Notifizz has to fill it per recipient, and remove it entirely on transactional mail. Replace the link's destination with the placeholder and publish again.
Not while it is the default: your organisation must always have one, and archiving it would leave your emails without an envelope. Promote another layout to default — that un-sets the current one in the same move — then archive it.
No. Text, Image, Button and Spacer belong to Notifizz, not to your organisation, so they are neither counted nor deletable. Only components your organisation owns are metered.
Two different limits can refuse it. A single image above 5 MB, or in a format outside PNG, JPEG, GIF, WebP and AVIF — SVG included, deliberately — is refused on its own merits. Otherwise your organisation is at its storage ceiling: delete images you no longer use (archiving hides them but keeps the bytes) or raise the plan.
No. In-app messages compose from a fixed set of slots — visual, title, date, text, buttons — rather than from reusable blocks, because the widget owns its own layout. The library described here is the email one. See [channels in detail](/docs/concepts/channels-detail).
## See also
Import the emails you already own into this library, deduplicated.
Where brand tokens and reusable variables are defined.
How a CTA destination becomes a real, tracked URL.
Where an email step sits in a campaign, and how it is sent.