The default use case
Every project starts with a default use case. Here is what it is for, why its emails carry the unsubscribe footer, and what happens to a send that names no use case.
Every email you send through NevarMail belongs to a use case — the "why" behind the message (order receipts, a weekly digest, sales outreach). Use cases live inside a project. When you create a project, NevarMail creates its default use case with it, named General, so there is never a moment when a project exists but has nowhere to file a send.
What the default use case is for
- It is the use case a send lands in when you don't name one. A send from the API, the SDK, the MCP server, a template, a scheduled email or a sequence that carries no
use_case_idis attributed to the default use case of the project it runs in. Every send is therefore traceable to a use case — nothing is ever "unfiled". - It is the starting point for a new project. Onboarding's first email goes out under it. You can keep using it, rename it, or make another use case the default later.
- There is exactly one per project. Making a different use case the default swaps it within that project only; other projects keep theirs.
Why its emails carry the unsubscribe footer
The default use case is suppressable: recipients can opt out of it. Any email sent under a suppressable use case carries the compliance footer — an unsubscribe link and your postal address — and the List-Unsubscribe headers that let mail clients offer one-click unsubscribe.
That is deliberate. A send that names no use case is a send NevarMail knows nothing about. Treating it as opt-out-able is the safe default: a recipient who did not want it can always stop it, and you are never the sender of a message with no way out. If you have mail that genuinely must not be opt-out-able — password resets, receipts, security alerts — create a use case for it, switch off Suppressable, and name it on those sends. That is the explicit choice; the default is the careful one.
The default use case cannot be made non-suppressable, and a non-suppressable use case cannot become the default.
One consequence: an email under a suppressable use case cannot carry cc or bcc. One message carries one unsubscribe identity, minted for the to address, so a copied recipient's unsubscribe click would opt out the primary recipient instead of themselves. That rule already applied to marketing sends; it now applies to every send under a suppressable use case, including the default. Send each recipient their own message, or name a non-suppressable use case for mail that genuinely needs copies.
What you need before the first send
The footer states who sent the email, so NevarMail needs your postal address before it can send anything under a suppressable use case. Onboarding asks for it on the first-send step; afterwards it lives in Settings → Marketing. A send under the default use case with no address on file is refused with COMPLIANCE_ADDRESS_REQUIRED — nothing goes out without the footer.
You do not need to switch on marketing sending for this. That switch is about sending emails typed marketing; the footer on a suppressable use case only needs the address.
The System use case
Alongside the default, every project gets a System use case that is not suppressable and is never the default. NevarMail files the mail it sends on your behalf there: team invitations, replies from your inboxes, chat relays, inbound forwards, and the deliverability probe. That is relationship mail with no opt-out, so it carries no footer and may include cc. A send from your own code never lands in it unless you name it.
Sends that name no use case
| Where the send comes from | Which use case it lands in |
|---|---|
POST /api/v1/email/send, /schedule, /send-to-list without use_case_id | the default use case of your organization's default project |
The SDK (@bernierllc/nevarmail) and MCP tools without a use case | same as above |
| A sequence created without a use case | the default use case of its project |
| Compose inside a project, without picking a use case | that project's default use case |
Naming a use case explicitly (use_case_id) always wins. It is also the only way a send is trusted to narrow a suppression check: a send filed under the default because you named nothing still honors every opt-out the recipient has ever made in your organization.
Related pages
- Set up what you send, and why — the onboarding step where the default use case is first used.
- Unsubscribes and compliance — what the footer and suppression actually do.
- Sending email — the
use_case_idfield on every send endpoint.
Set up what you send, and why
Use cases organize your sending by purpose. Here is how the first one gets created, and why your first email can only go to you.
Set up SPF, DKIM and DMARC for your domain
Why mailbox providers need your domain verified, what records to add, and how to tell when it has worked.