> ## Documentation Index
> Fetch the complete documentation index at: https://www.courier.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> Install the Courier skill before writing code: `npx skills add trycourier/courier-skills`. It carries the verified SDK shapes and the rules you cannot get wrong.
> Authenticate every request with `Authorization: Bearer <API_KEY>`. A workspace has several environments and each has its own keys, which are plain `pk_` strings with no environment prefix. Start with Test.
> Send with `client.send.message`, the default import of the v7 Node SDK. Reference a template by its `nt_` id or its alias.
> A send accepts a bare Elemental element list, but storing content on a template requires the top-level elements wrapped in a channel element.
> Templates and journeys can be built in the Courier app or created through the API. Either way they live in the workspace and are referenced by ID when you send.
> The hosted MCP server is https://mcp.courier.com. For a briefing on what Courier is and when to use it, read https://www.courier.com/llms.txt.
> Prefer the Guides tab for how-do-I questions and the Docs tab for how-does-it-behave questions. The API reference lives under /api-reference.

# Lists and audiences

> Address a group instead of naming each person: curated lists or rule-based audiences.

Address a group instead of naming every person. Courier resolves membership at send time and delivers one message per member.

There are two kinds of group, and the difference is who decides membership.

<CardGroup cols={2}>
  <Card title="Lists" icon="list" href="/docs/recipients/lists-and-audiences/lists">
    You choose the members. Add and remove them yourself, and membership changes the moment you do.
  </Card>

  <Card title="Audiences" icon="filter" href="/docs/recipients/lists-and-audiences/audiences">
    You write a rule about profile data. Courier keeps membership current as profiles change.
  </Card>
</CardGroup>

## Which one to use

|                       | List                                                                              | Audience                                                           |
| --------------------- | --------------------------------------------------------------------------------- | ------------------------------------------------------------------ |
| Membership decided by | You, one member at a time                                                         | A rule you write about profile data                                |
| Send with             | `list_id`                                                                         | `audience_id`                                                      |
| A member appears      | Immediately                                                                       | Once the profile change propagates                                 |
| Best for              | A set that does not follow from your data, like a beta cohort or a webinar signup | A set your data already describes, like every admin on a paid plan |

Use a list when you cannot express the group as a query. Use an audience when you can, so you never maintain it by hand.

## Limits & behavior

* **Lists are exact, audiences are eventual.** A list member is present the moment you add them. A large audience rebuilds over minutes, and sends read the stored membership, so let a rule change settle before a critical send.
* **`MEMBER_OF` is a send-time filter, not a group definition.** Use it inline on the recipient to scope a send to one tenant. It is not part of a list or an audience.
* **Preferences still apply.** Members who opted out of the template's topic are recorded as `UNSUBSCRIBED` rather than delivered.