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

# Core concepts

> The ideas the rest of the documentation assumes: organizations, subscriptions, sender identities, credits and the send checklist.

These are the terms the rest of the docs use without explaining. Everything hangs off one idea: an
**organization** owns an audience and the right to reach it on certain channels. Each piece below
depends on the one before it, which is why setup follows the same order.

```mermaid theme={"system"}
flowchart LR
  Org["Organization"] --> Sub["Subscriptions"]
  Org --> Wal["Wallet"]
  Org --> Con["Contacts"]
  Sub --> Ch["Channel"]
  Ch --> SI["Sender identity"]
  SD["Sending domain"] --> SI
  Con --> LS["Lists and segments"]
  SI --> Camp["Campaign"]
  LS --> Camp
  Wal --> Camp
```

## Organization

The top-level container. Contacts, campaigns, domains, API keys, subscriptions, invoices and the
credit wallet all belong to one organization.

* People join an organization as members with the `owner`, `admin` or `member` role. See
  [Members and roles](/organization/members-and-roles).
* One login can belong to several organizations and switch between them from the organization
  switcher at the top of the sidebar. Your own account settings are shared; everything else is
  separate.
* A platform API key belongs to exactly one organization, so every API request acts on that
  organization.

## Product and subscription

Each channel is sold as its own product: Email, SMS, WhatsApp and Push. Mailbox is a product too.
You subscribe to a product's plan in **Billing & Plans**, and plan tiers are `free`, `starter`,
`growth` and `enterprise`.

A new organization starts on a free email plan. Email and push need an active subscription to send.
SMS and WhatsApp are paid per message from the wallet instead. See
[Plans and subscriptions](/billing/plans-and-subscriptions).

## Channel

The medium a message travels over: email, SMS, push (through Firebase Cloud Messaging) and
WhatsApp. WhatsApp is in early access: you can connect a business number and prepare templates, but
sending isn't generally available.

Each channel has its own page under **Channels**, with a **Setup** tab listing what it still needs.
See [Channels overview](/channels/overview).

## Sender identity

Who a message comes from: a sender address on email, a sender ID on SMS, a business number on
WhatsApp. Every channel except push needs one, and each channel proves your right to use it in its
own way. An email sender address needs no review, because verifying its domain already proved you
control it. An SMS sender ID is reviewed by Brudcast, then approved by carriers country by country,
and it only sends where it's approved.

Push has no sender identity. You connect your own Firebase project instead, and Brudcast checks its
credential with Firebase.

For the full table and the review statuses, see
[Sender identities](/channels/overview#sender-identities).

## Managed sending address

Every new organization is issued an email address on `brudcastmail.com`, of the form
`mail@<label>.brudcastmail.com`, so it can send before setting up DNS. The dashboard calls it your
**Brudcast trial address**. It sends campaigns only, it's capped at 500 emails a day or your
[new-account sending limit](/deliverability/new-account-sending-limits) if that's lower, and it
retires 14 days after you verify a domain of your own.

See [Email channel overview](/channels/email/overview).

## Sending domain

A domain you own and have verified for sending email, by publishing five DNS records. It carries
your SMTP users, sending keys and tracking settings.

A domain moves through `provisioning`, `unverified` and `verified`. It can also be
`provisioning_failed`, `verification_failed` or `suspended`. See
[Add a sending domain](/channels/email/add-a-sending-domain).

## Mail domain

A domain set up under **Mailboxes** so your team can read and reply from real inboxes, such as
`jane@example.com`. It's a different job from a sending domain: a sending domain carries outbound
campaign, API and SMTP mail, while a mail domain receives person-to-person email and holds
mailboxes. They need different DNS records and they're paid for as different products.

The same domain name can be both. When it is, the two share one SPF record and one DMARC record,
because a domain may publish only one of each. See [Hosted mailboxes](/mailbox/overview).

## Contact and channel identity

A contact is a person, not an address. It holds a profile plus one or more **channel identities**:
an email address, a phone number for SMS, a WhatsApp number, or a push device token. Each identity
has its own subscription status.

That's why a multi-channel campaign can reach the same person on each channel you have for them.
See [Contacts overview](/contacts/overview).

## List and segment

A **list** holds the contacts you put in it. A **segment** holds the contacts that match its rules,
and can be dynamic or static. You can convert a segment into a list to freeze its membership.

See [Contacts overview](/contacts/overview) and [Segments](/contacts/segments).

## Campaign

One message sent to an audience across one or more channels. A campaign has content for each
channel, an audience of lists, segments and contacts minus exclusions, delivery settings, and an
optional A/B test.

Its statuses are `draft`, `scheduled`, `sending`, `sent` and `completed`, and it can also be
`paused` or `cancelled`. See [Campaigns overview](/campaigns/overview).

## Credits and the wallet

Sends are metered in credits, held in the organization's wallet and bought as top-ups.

<Snippet file="credit-costs.mdx" />

* **SMS and WhatsApp are wallet gated.** Without enough credits the send is blocked, even on an
  active plan.
* **Email and push overflow.** Credits are only used for sends beyond your plan's allowance.
* When a campaign sends, it reserves the credits it needs for every channel at once, then settles to
  what was actually used and releases the rest.

See [Credits and wallet](/billing/credits-and-wallet).

## Send checklist

The list of things a campaign needs before it can go out. The composer shows it beside the
content, and the **Send** button reads **Send · 2 items left** until every item is clear.

| Item         | What it asks for                                                                                    |
| ------------ | --------------------------------------------------------------------------------------------------- |
| **Audience** | At least one list, segment or contact                                                               |
| **Content**  | A subject and body for email, a message for SMS, a template for WhatsApp, a title and body for push |
| **Sender**   | A sender on every selected channel                                                                  |
| **Credits**  | Enough wallet credits for the channels that use them                                                |

When you send, Brudcast also checks that the email from address sits on a verified sending domain
(or is your managed sending address, used as issued). It also checks that your organization has a
postal address on file and that email and push have an active subscription. See
[Send checklist](/campaigns/send-checklist).

## The life of one message

```mermaid theme={"system"}
flowchart TD
  A["Campaign, API call or SMTP message"] --> B{"Checks pass?"}
  B -- No --> R["Refused with a reason"]
  B -- Yes --> Q["Queued"]
  Q --> S{"Recipient suppressed?"}
  S -- Yes --> D["Dropped, nothing sent"]
  S -- No --> M["Handed to the receiving server"]
  M --> O["Delivered, bounced or deferred"]
  O --> E["Opens, clicks, complaints"]
  O --> W["Reports and webhook events"]
  E --> W
```

* **Checks.** A campaign won't send until its [send checklist](/campaigns/send-checklist) is clear.
  An API or SMTP message is checked against its credential, its from-domain and your limits.
* **Queued.** The send API answers `202` with a `jobId` at this point. Queued means accepted for
  delivery, not delivered.
* **Suppressed.** Addresses on your organization's [suppression list](/contacts/suppressions) are
  dropped without being sent.
* **Delivered.** The receiving mail server accepted the message. That's a different claim from
  "reached the inbox" or "was opened".

Where all of this lives in the dashboard is covered in
[Dashboard tour](/get-started/dashboard-tour).

## Related

<Columns cols={2}>
  <Card title="Quickstart" icon="rocket" href="/get-started/quickstart">
    Use these pieces to send your first email.
  </Card>

  <Card title="Channels overview" icon="radio-tower" href="/channels/overview">
    What each channel needs before it can send.
  </Card>

  <Card title="Contacts" icon="users" href="/contacts/overview">
    Contacts, channel identities, lists and segments in practice.
  </Card>

  <Card title="Campaigns" icon="send" href="/campaigns/overview">
    Build a campaign, clear the send checklist and send it.
  </Card>

  <Card title="Credits and wallet" icon="wallet" href="/billing/credits-and-wallet">
    What each message costs and how to keep the wallet funded.
  </Card>

  <Card title="Dashboard tour" icon="layout-dashboard" href="/get-started/dashboard-tour">
    The sidebar, the command palette, notifications and live updates.
  </Card>
</Columns>