Senders and mailboxes
Senders manages suppression, mailbox health, sender identities, and sender policy.
Senders controls the identities and policy boundaries used for outbound work. Use it to inspect mailboxes, social accounts, sending domains, rotation, health, or do-not-contact rules before a sequence starts delivery.
Senders is a control pack. Sequences and enrollment owns cadence and lifecycle, while an existing conversation belongs to Inbox. A sender setting can block delivery without changing the sequence's draft or recipient-selection logic.
Sender policy and identity
The senders pack owns suppression, do-not-contact rules, mailbox health, rotation, sender identities, sending domains, and sender policy. It is the right boundary for an answer to "can this workspace send to this person through this channel?" It is not the right boundary for provider OAuth, an outreach cadence, or a reply inside an existing thread.
Connected social-account identifiers are available from senders.social_accounts.list. Social draft, publish, comment, and analytics contracts refer to those identifiers when an operation needs a specific account. Some content contracts accept no account id when the workspace has exactly one connected account for a selected channel; when several accounts exist, the returned account list is the safe source for choosing the intended identity.
Mailboxes are distinct from social accounts. The sender pack supplies mailbox reads, mailbox health checks, mailbox updates, rotation configuration, and capacity or purchase operations. A mailbox or domain configuration can control whether a later sequence step can run, but configuring it does not itself compose, publish, or enroll a sequence.
Settings is the app location for sender policy. Keep the sender identity separate from the recipient record: the identifier identifies who sends, while the recipient's email or LinkedIn URL identifies whether the sequence can deliver on a chosen channel. This separation makes a failed delivery diagnosable without changing the wrong account.
| Sender area | What it covers |
|---|---|
| Sender identity | Mailboxes, connected social accounts, sending domains, and rotation. |
| Mailbox health | Readiness, health, capacity, and sender policy before an outbound run. |
| Suppression | An email, domain, phone, company, LinkedIn identity, or X handle blocked from future outbound contact. |
| Imported policy | A Dreamstate worksheet import or a CRM sync that adds new blocked members. |
Suppression is a workspace policy
A suppression blocks a stored email address, email domain, phone number, company, LinkedIn identity, or X handle from all future sends and outbound channels. Use it when the policy needs to survive a particular sequence, mailbox, or campaign. Removing a person from one enrollment does not express the same workspace-wide no-contact policy.
The sender pack can import suppressions from a Dreamstate worksheet. CRM lists can also stay in sync so new members are blocked automatically. These integrations add to the sender-owned local ledger; the integrations pack still owns the third-party connection that may make a CRM source available. Read Do not contact for the identifier scopes, imports, and recovery rules before changing a suppression.
Suppression writes converge on one normalized row. Repeating a write does not create a duplicate policy row, and deleting an already absent row remains safe. The write controls are synchronous, free, and internally reversible according to their catalog policies, but the result matters because future outbound channels will use the rule when deciding who can be contacted.
A reply, bounce, unsubscribe, suppression, decline, wrong-person result, or finished conversation ends outreach to that person across channels. Do not work around such a stop by changing the sender, sequence, or channel. Read the current thread and suppression state before retrying a delivery or making a policy change.
Check readiness before a live action
Before a live outreach action, read the intended sender identity, mailbox readiness, sender health, daily capacity, timing policy, and current suppression ledger. Then read the target recipient data and the selected sequence state. These checks establish whether the action has an eligible sender and a contactable recipient; they do not send a message or change the sequence.
A sequence delivery plan reports blockers with four real kinds: no_connected_sender, suppressed_or_do_not_contact, missing_email, and missing_linkedin_url. Each blocker also records whether the affected channel is email or LinkedIn. Treat a blocker as a specific repair instruction rather than a generic send failure.
A missing sender blocks running or sending the affected step, but it does not block creating a worksheet, drafting a sequence, validating its configuration, or preparing an audience. Build those local artifacts first, then connect or select the needed sender before the execution step. A missing recipient email or LinkedIn URL is a recipient-data problem, not a reason to change the sender account.
Architect can inspect sender readiness through the live catalog. It should route sender policy to the senders pack, retrieve the exact schema, and preserve the result identifiers for a later read. The agent should not infer a specific mailbox from a profile label or assume that an account in another workspace is available here.
Before this outreach runs, inspect the selected sender, mailbox health, and do-not-contact policy for the recipients. Report every delivery blocker and its channel. Do not send, enroll, or change a sender setting.Sequence and sender boundary
A sequence owns templates, cadence steps, sends, reminders, follow-ups, LinkedIn engagement actions, campaign planning, launch, pause, and lifecycle state. The sender pack owns the identity and policy checks that make a delivery eligible. Publishing or enrolling a sequence does not itself send; sending starts only with an explicit start action in the sequence lifecycle.
Send capacity is paced over days rather than minutes. A capped or delayed cell can be pacing rather than a delivery failure. Read daily limits, sender health, selected channel, recipient identity, and suppression state before changing a schedule. A sender policy never turns a reply into permission for a further outreach attempt, and a new channel never bypasses a workspace stop.
Use a sender read when you need evidence about a mailbox or social identity. Use a sequence read for cadence, enrollment, validation, launch, or outcome totals. Use Inbox for an existing conversation. This three-way boundary avoids treating a delivery status as a conversation reply or treating a conversation state as proof that a sender was eligible to deliver a message.
Sender actions can carry different effects. A list or health read is read-only. Rotation configuration is a synchronous, internally reversible write and requires idempotency. Mailbox purchase or cancellation reaches an external provider and uses an idempotency boundary. Fetch the exact capability before changing policy because the catalog, not this conceptual page, defines its input, cost, scopes, and result shape.
Cost, modes, and results
Sender catalog entries disclose their own credit class, action policy, cost policy, asynchronous policy, and required scopes. Catalog credit classes are free, action, and dynamic. A capability with a sender noun is not automatically free or read-only, so inspect the fetched descriptor before relying on a cost assumption.
Every mutating action must name a mode. smoke_test inspects schema and policy without writing or recording an audit entry. dry_run validates against workspace state without business writes, provider spend, or outward action. live executes only after the returned contract permits it. The server returns mode_required instead of defaulting a mutation to live.
Paid live work can return quote_required. Re-run the same request with unchanged parameters and a max_credits ceiling. This is the credit consent boundary for the run. It is distinct from owner actions, which are security-sensitive changes such as credentials and require a signed-in session, fresh approval at the applicable tier, and an Idempotency-Key.
State-bearing results can include a web_url for the related screen in the app. Keep returned JSON ids as the source of truth, then use the URL to inspect the mailbox, sender, suppression, or related object. A result identifier lets a later run or an agent turn refer to the same state instead of guessing which sender configuration changed.
When it goes wrong
If a delivery reports no_connected_sender, inspect the intended channel and connect or select an eligible sender. Do not edit recipient data or remove a suppression. If it reports missing_email or missing_linkedin_url, correct the needed recipient field and keep the selected sender configuration intact.
If the blocker is suppressed_or_do_not_contact, read the matching policy row and identifier scope. Do not move the person to another channel or sender. Resolve the workspace's policy outside the send attempt, then verify the final ledger before attempting any future outreach.
If delivery is delayed, inspect caps, health, timing policy, and sequence state before calling it failed. If the recipient replied, bounced, unsubscribed, declined, or is the wrong person, do not restart the lead's run. Read the full conversation and sender evidence, because a reply ends outreach across channels.
If a mutation returns mode_required, use a supported mode from the fetched schema. If it returns quote_required, retain the same parameters and provide the intended credit ceiling. If the action is an owner change, use the signed-in owner flow and idempotency key rather than trying to perform the action with an API key.