A **Topic** is a named stream of mail a recipient can opt out of on its own — "Product updates," "Weekly digest," "Onboarding." Topics are what make an unsubscribe **granular**: a contact can leave one topic without going globally unsubscribed. Every Topic is backed by a topic on your connected AWS SES contact list, so subscription preferences are enforced by SES itself, not just tracked in SendOps.

Topics live in the **Audience** area of the SendOps dashboard. See [Consent & lifecycle mail](/sending-email/consent-and-lifecycle#topics-are-opt-out-streams) for how a Topic fits into the wider consent model that decides whether a send actually goes out.

## The Topics page

The **Topics** page lists every Topic in your organization. Each row shows:

- **Display name** — the human-readable name shown to recipients on the unsubscribe page.
- **Name** — the stable, org-unique key your own systems and Segment rules refer to (`subscribed to "<name>"`).
- **Default subscription** — whether a newly imported or created contact starts **opted in** or **opted out** of this Topic (see [Default subscription status](#default-subscription-status) below).
- **Subscribers** — how many contacts currently have an active subscription to the Topic.
- **Origin** — `Managed` (created in the dashboard or via the API) or `Git` (declared in your connected repository).
- **Status** — `Active` or `Archived`.



## Creating and editing a Topic

A **managed** Topic has four fields:

- **Name** — the stable key. Used in Segment rules and referenced by your own systems; choose it carefully, as it's what identifies the Topic everywhere else.
- **Display name** — what recipients see on the unsubscribe page. Defaults to the name if you don't set one.
- **Description** — optional notes on what mail this Topic covers.
- **Default subscription status** — `Opted in` or `Opted out` (see below).

Archiving a Topic hides it from the picker used when composing a send, without deleting existing subscriber preferences or history.

### Default subscription status

**Default subscription status** governs whether a contact starts **subscribed** or **not subscribed** to the Topic the moment they're added to your audience (imported, created via the API, or synced from SES):

- **Opted in** — new contacts start subscribed. Use this for topics recipients would reasonably expect by default (e.g., account notices grouped under a topic).
- **Opted out** — new contacts start **not** subscribed; they have to actively opt in before you can send them that topic's mail. Use this for anything closer to pure marketing.

Changing the default only affects contacts added **after** the change — it never silently re-subscribes or unsubscribes anyone already on the list.

## Using Topics in sends and rules

- **Broadcasts** send under a Topic so the topic tier of consent is enforced — see [Broadcasts](/sending-email/broadcasts).
- **Drip Workflow** `send` steps choose a Topic with `via topic "<name>"`, or inherit a template's default — see [Sends, consent & approval](/workflows/sends-and-approval).
- **Segment rules** select on subscription state with `subscribed to "<name>"` and `opted out of "<name>"` — see [Segment syntax](/audience/segment-syntax#consent-and-membership).

## Managing Topics as code

Like [Lists](/audience/lists), [Segments](/audience/segments), and [Attributes](/audience/attributes), Topics can be authored **as code** in your connected repository instead of the dashboard. The `topics` key of your `sendops.json` manifest is a **path to a JSON file** — relative to the manifest, no `..` segments, ending in `.json` — and that file holds a map of topic name to definition:

```json
// sendops.json
{
  "topics": "audience/topics.json"
}
```

```json
// audience/topics.json
{
  "product-updates": {
    "display_name": "Product Updates",
    "description": "New features and improvements.",
    "default_subscription_status": "OPT_OUT"
  },
  "weekly-digest": {
    "display_name": "Weekly Digest",
    "default_subscription_status": "OPT_IN"
  }
}
```

Unlike Segments (one file per segment, referenced individually in the manifest), all of an org's git-backed Topics live together in the single file `topics` points at. Each key is the Topic's `name`; `display_name` and `description` are optional, and `default_subscription_status` defaults to `OPT_OUT` when omitted.

A git-backed Topic is **read-only in the app**, following the same [managed vs git-backed authoring](/audience/managed-vs-git-authoring) model as the rest of your audience definitions — edit it in the repository and open a pull request; the next sync brings the change in. You can **Promote** a managed Topic into git, or **Adopt** a git-backed one back into the dashboard.


  Promoting or adopting a Topic only changes where its *definition* is authored (display name, description, default). Subscriber preferences always live on the underlying SES contact list and are unaffected by which side owns the definition.


## What's next?

- [Consent & lifecycle mail](/sending-email/consent-and-lifecycle) — the full consent model a Topic plugs into.
- [Managed vs git-backed authoring](/audience/managed-vs-git-authoring) — the shared model behind Promote and Adopt.
- [Segment syntax (SendQL)](/audience/segment-syntax#consent-and-membership) — selecting contacts by Topic subscription.
- [Lists](/audience/lists) — static audiences with explicit membership.