Core concepts

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.

​

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.
• 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.

​

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.

​

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.

​

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 if that’s lower, and it retires 14 days after you verify a domain of your own. See Email channel 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.

​

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.

​

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.

​

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 and 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.

​

Credits and the wallet

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

• 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.

​

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. 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.

​

The life of one message

• Checks. A campaign won’t send until its 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 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.

​

Related