> ## Documentation Index > Fetch the complete documentation index at: https://notifizz.com/llms.txt > Use this file to discover all available pages before exploring further. # Notification Preferences and Categories > Notification categories, the hosted preference centre your subscribers use, and the consent layers applied before every send — including the cap that keeps promotional email honest. # Notification preferences Consent is not a checkbox your code carries around. In Notifizz it is a small system: **you** name the kinds of message you send, **your subscribers** choose which ones they want, and the platform applies those choices before every single send — without your orchestrator having to know. Three roles meet on this page. **Marketing** defines the categories and lives with the four-category cap. **Dev** needs to know what is enforced, in what order, and what a dropped recipient looks like in the statistics. **Ops** answers the person who says they unsubscribed and got mail anyway. ## TL;DR * Two kinds of category: **transactional** (mandatory, never opt-out-able) and **promotional** (optional). Defined once per organisation, shared by every environment. * **At most four promotional categories.** The cap is deliberate — beyond it the opt-out page pushes people to unsubscribe from everything. * Every promotional email carries a **one-click unsubscribe** and a footer link to a **hosted preference centre**, themed with your Brand Kit. Transactional email carries neither. * Before every send, two layers run in order: **suppression** (hard, organisation-wide, fail-closed), then **subscription preferences** (promotional only). * **Absent means subscribed.** Preferences are an opt-out model; a person who never touched the page receives everything. * Nothing is swallowed: recipients dropped for consent are counted in the campaign's statistics, by reason. ## Categories A category answers one question: **why** is this message being sent? That single answer decides whether the person may refuse it. ### The two types | | Transactional | Promotional | | ------------------------------- | ------------------------------------------------------------------------------------ | --------------------------------------------------------------------- | | Examples | Password reset, order confirmation, two-factor code, shipping update, security alert | Newsletter, product update, onboarding nudge, win-back, weekly digest | | Can a subscriber opt out? | **No** — the message completes an action they took | **Yes**, per category or all at once | | Listed on the preference centre | Never | Always | | Carries an unsubscribe link | No — the link is stripped at render | Yes, guaranteed | | Delivery priority | Highest | Lower than transactional | | How many can you define | Unlimited | **Four** | The split is not cosmetic. It decides three separate behaviours — whether the message can be refused, whether it ships with an opt-out surface, and where it sits in the sending order — from one declaration. ### Where categories are defined **Settings → Subscribers & privacy → Unsubscribe categories.** Each category carries a **name** and an optional **description**, and both are shown to your subscribers on the preference centre — write them for the reader, not for your backlog. *Weekly digest* and *Product announcements* are categories; *Campaign batch 3* is not. Categories are **per organisation, not per environment**: the same set applies to production, staging and every sandbox, so a preference expressed once is understood everywhere. Two constraints worth knowing before you start naming things: * **The type is fixed at creation.** You can rename a category and rewrite its description afterwards; you cannot turn a promotional category into a transactional one. Promoting a message people opted out of into a category they cannot refuse is precisely the move the platform will not let you make quietly. * **Deleting a category is not blocked** by the campaigns that reference it. Repoint those campaigns first, or you leave them pointing at a category nobody can see or manage any more. ### Why only four promotional categories Because the fifth one costs you subscribers. The cap exists to protect the page the subscriber actually reads. Past roughly four choices, a preference centre stops being a menu and becomes a wall of switches — and the reliable human response to a wall of switches is the big button at the bottom that turns everything off. Worse, a long list of narrow categories is a recognised unsubscribe-evasion pattern: it looks like choice while making a full opt-out tiring to express. The API refuses the fifth promotional category outright, and the settings screen tells you the count as you go (`Promotional · 3/4`). Transactional categories are uncapped — they never appear on the page, so they cannot crowd it. Start with two or three broad groups and split further only if you see real opt-out friction. Fragmenting early is easy; merging categories once people have expressed preferences against them is not. ### Attaching a category to a campaign A campaign carries a **campaign category**, chosen in its category editor: | Campaign category | What it is | Promotional? | Named sub-category | | ----------------- | ------------------------------------------------------------------------ | ------------ | ------------------------------------------------- | | `Transactional` | Event-triggered, completes a user action | No | Never | | `Product` | Event-triggered, optional — digests, engagement, lifecycle | Yes | **Yes** — pick one of your promotional categories | | `Marketing` | A [broadcast](/docs/concepts/broadcasts): launched against a CRM segment | Yes | No — its opt-out is the global promotional one | So the named categories you define are attached to `Product` campaigns. A transactional campaign never carries one, and a marketing broadcast is governed by the global promotional opt-out rather than by a theme. The campaign category and its named sub-category can only be changed while the campaign is in **Editing**. Once it has moved on, the classification is frozen — create a new editing version to change it. Consent classification is not something to flip under a `Live` campaign. ## The preference centre Every promotional email leads to a **hosted page** where the person manages what they receive from you. You do not build it, host it, or link it by hand. ### What the subscriber sees * Their address, **masked** — `a•••@example.com`. Enough to confirm which inbox they are managing, never enough for the page to leak an address to whoever opens the link. * One row per **promotional** category, with its name and description, and a checkbox. The category the email they just received belongs to is **highlighted**, so the obvious action is to silence *that* theme rather than everything. * A single button: **Unsubscribe from all**, or **Re-subscribe** if they are already opted out of everything. * Your **logo, brand name and colours**, taken from the global Brand Kit. The page is never an unstyled orphan page that looks like a phishing attempt. Turning off everything shows an explicit reassurance rather than leaving them guessing: they still receive transactional messages — receipts, security alerts — and the per-category switches go quiet until they re-subscribe. ### Two states that are not failures | Situation | What the page does | | -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | The link is old, altered or expired | A neutral page: the link is no longer valid, use the one from a more recent email. It never says *why* it failed. | | The address is on the suppression list | The page becomes read-only and says what is blocked — all email, or promotional only, with transactional still arriving. A suppression from a spam complaint or an erasure request says so: it cannot be undone from this page. | Both are deliberate. A page that explained exactly why a token failed would be a probing tool, and a page that let a suppressed address re-subscribe itself would undo a legal obligation with a mouse click. ### The opt-out model **A category the person has never touched counts as subscribed.** Preferences store refusals, not consents — so a category you add tomorrow is on by default for everybody, and nobody has to revisit the page to keep receiving what they already receive. Two consequences to hold on to: * **Unsubscribe from all** is recorded as a global promotional refusal and is honoured **across your whole organisation** — a person who opts out in one place is not reachable from another environment. * Updating preferences **merges**, never replaces. Changing one category leaves every other choice standing. The dashboard-side write and the subscriber-side write behave identically here, so your organisation can never silently overwrite a person's own decision. ## One-click unsubscribe Promotional email also carries the opt-out **in its headers** — the one-click standard (RFC 8058) that Gmail, Yahoo and the other large mailbox providers now expect from bulk senders, and surface as their own *Unsubscribe* affordance next to the sender name. | Send | Header opt-out | Footer link | | ------------- | ------------------------------------- | ------------------------------------------------- | | Promotional | Yes — one click, no confirmation page | Yes — guaranteed, even if the template forgot one | | Transactional | No | No — the link is removed at render | Three properties are worth spelling out: * **One click means one click.** The mailbox provider posts the opt-out and the person is unsubscribed from all promotional email; nothing asks them to confirm on a landing page. It is idempotent, and it is reversible from the preference centre. * **The link is server-derived, per message.** It is built at render time from the message itself and signed — the campaign's AI orchestrator can neither produce it nor override it. A personalisation bug can break many things; it cannot break somebody's opt-out. * **A promotional email always ships with a working opt-out.** If the template carries no unsubscribe link, a footer is appended deterministically. Templates you author must place the reserved unsubscribe placeholder exactly once, and never a hardcoded URL — the editor refuses the layout otherwise, because a hardcoded link would ship verbatim on a transactional send and never resolve to the recipient's real opt-out. ## What is checked before every send Consent is enforced by the platform, **after** the campaign's orchestrator has produced its recipient list and **before** fan-out — recipient by recipient. You do not re-implement it. On email, two layers run in this order: | Order | Layer | What it holds | Applies to | | ----- | ----------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------- | | 1 | **Suppression** (hard) | Email hashes, organisation-wide. Fed by hard bounces, spam complaints, erasure requests, and manual additions. Scope-aware: an `all` entry blocks every email including transactional; a `promotional` entry blocks marketing only. | Every send | | 2 | **Subscription preferences** (soft) | The person's own choices: the global promotional opt-out, then the per-category one. | Promotional sends only | Suppression is checked **first and always wins** — a hard suppression overrides any preference, and the check is **fail-closed**: if the list cannot be read, the recipient is dropped rather than emailed. Emailing a suppressed address because of a transient glitch is the one failure that cannot be taken back. The preference read is deliberately the opposite, fail-open: a transient error must not silently drop a legitimate send. **Transactional sends never consult preferences.** There is no configuration that makes a password reset opt-out-able, and that is the point of the classification. ### Other channels | Channel | How consent is applied | | ------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Email | The two layers above | | Web push | The browser permission is the consent — no subscription, no delivery, structurally. A promotional push additionally honours the person's promotional refusals on the same record. | | Notification Center | No send-time consent gate: an in-app inbox is a surface the person opens deliberately. | ### Where the drops show up Nothing disappears quietly. Recipients removed for consent are counted in the campaign's statistics under their own reasons, next to the other drop causes: * **`suppressed`** — the address is on the suppression list, with a scope covering this send. * **`unsubscribed`** — a promotional send, refused by the global opt-out or by the category switch. A campaign that reached fewer people than you expected is answerable from that breakdown, which is exactly why the reasons are distinct rather than merged into one "skipped" bucket. ## FAQ Almost always: it was transactional. A password reset, a receipt or a security alert is sent regardless of any preference, by design and by law in most regimes. Check the campaign's category on the record in [Audience](/docs/concepts/audience) — the campaign history shows which campaign the message came from. No — the API refuses it, not just the screen. Merge two existing themes, or make the new one transactional if it genuinely completes a user action. If four feels tight, the usual cause is categories named after campaigns rather than after what the subscriber recognises. No. The preference centre is hosted, themed from your Brand Kit, and linked automatically from every promotional email. There is nothing to deploy and no route to expose on your side. If they simply opted out, yes — they re-subscribe themselves from the preference centre, using the link from any earlier promotional email. If they are on the suppression list, no: the page is read-only for a suppressed address, and there is no self-service removal. A spam complaint or an erasure request is terminal by design; the other entries age out with the suppression-list retention you configure. The categories are — they are defined once for the organisation. A global promotional opt-out is honoured organisation-wide, and so is the suppression list. Per-person records themselves are per environment, so testing in a sandbox never touches a production subscriber's choices. Nothing stops the deletion, and the campaign keeps its now-dangling reference. The category disappears from the preference centre, so subscribers can no longer express a choice about it. Repoint the campaigns before deleting. It is complementary, not redundant. The platform layer answers "this person must never be emailed again" — legally, organisation-wide, fail-closed. Your orchestrator answers business questions: not to free-plan accounts, not twice in one month. Keep the second, never re-implement the first: an orchestrator-level opt-out has none of the guarantees this one has. ## See also The per-person record — identities, history, and GDPR requests. Where a campaign gets its category, and when it can still be changed. Hashing, retention dials, and the suppression list's legal floor. Where consent sits in the send pipeline, from the developer's side.