---
title: Topics
description: Reading the topics people can consent to.
---

Topics are what somebody consents to receive. See [core
concepts](/guide/concepts#topic) for why they exist and why they are
not lists.

## List topics

`GET /v1/topics`

```bash
curl https://api.zevcampaign.com/v1/topics \
  -H "Authorization: Bearer sk_live_your_key_here"
```

```json
{
  "data": [
    {
      "id": "tp_7xk2m9qv4w",
      "name": "Weekly newsletter",
      "description": "A Friday round-up of what we shipped.",
      "brand_id": "br_3nf8q1",
      "requires_confirmation": true,
      "subscriber_count": 1842,
      "created_at": "2026-01-08T11:02:00.000Z"
    }
  ],
  "meta": { "limit": 20, "has_more": false, "next_cursor": null }
}
```

If your key is scoped to a brand, you see only that brand's topics.

`requires_confirmation` tells you whether a signup goes through double
opt-in. When it is `true`, [`/v1/subscribe`](/api/subscribe) answers
`confirmation_sent`; when `false`, `subscribed`.

`subscriber_count` counts confirmed subscribers only. Pending
confirmations are not included, because somebody who has not clicked
the link is not a subscriber.

## Creating topics

Topics are created in the dashboard, not over the API.

A topic is a promise to a recipient about what they will receive, and
its name appears on the unsubscribe page. Creating them from a script
tends to produce a catalogue of `list-1`, `list-2`, `test-topic`,
which is exactly what a person reading their preferences page should
never see.

## Using a topic id

Pass it as `topic_id` when subscribing, or in `topic_ids` when
creating a contact. Both validate the format and refuse an id that
does not belong to your workspace, or to your key's brand if it is
scoped.