Goal
Create explicit sending identities and share contact profiles within a brand while keeping audience consent independent.Prerequisites
- Keep Mail credentials on your backend. API examples use https://api.stackshift.cloud/v1 unless a public /api/v1 route is stated.
Workflow
1
Create the brand and its approved subscriber fields.
2
Create every audience with brandId; then create audience-owned campaigns/forms/segments/automations.
3
Use consent-aware imports and branded preference links; archive retired identities.
Brand endpoints and fields
- GET/POST /mail/brands lists or creates brands; GET/PUT /mail/brands/{id} reads or updates one; POST /mail/brands/{id}/archive archives it. Create returns HTTP 201; reads, updates and archive return HTTP 200.
- name is required, trimmed and limited to 120 bytes. Optional fields are logoUrl, sendingDomainId (UUID or null), defaultFrom, replyTo, postalAddress (up to 1,000 bytes), website, supportEmail and editableFields (up to 50 unique names).
- defaultFrom, replyTo and supportEmail must parse as email addresses without CR/LF and fit 320 bytes. website must be HTTPS without embedded credentials and fit 2,048 bytes.
- Editable names match ^[a-z][a-z0-9_]{0,63}$. These are the custom fields subscribers may edit; the shared name is also editable.
- Responses include id, workspaceId, mode, status (active or archived), revision, createdAt and updatedAt. PUT requires a positive current revision and the full desired brand fields, including name. Reload on a conflict instead of overwriting another edit. Unknown request fields are rejected.
Create a brand before its audience
Logo validation and sending domains
- Choose a current-version, public, ready, clean PNG, JPEG or GIF from the workspace’s default Assets space. The logo must be at most 5 MiB and use the configured CDN /assets/{assetId}/versions/{versionId} URL without a query or fragment. External image URLs, signed/private URLs, SVGs and arbitrary HTML/CSS are not accepted.
- Domains remain workspace-owned and reusable by brands. A sendingDomainId must belong to the workspace and environment. When it is set, defaultFrom must use that domain. Brand choice never bypasses live sender verification or a credential’s sender-domain restrictions.
- A brand is required for each audience; campaign, form, segment and automation ownership follows the audience. Cross-brand or cross-environment resource combinations are rejected. There is no default brand or audience fallback.
Shared profiles and independent memberships
- A contact profile is identified by brand plus normalized email within the workspace and environment. Name and custom attributes are shared across that brand’s lists; another brand has an independent profile.
- Each audience membership independently stores consent evidence, pending/confirmed state and subscription status. Updating a profile does not grant consent to another list.
- Preference pages show only existing memberships within the link’s brand and approved fields. The email address is not editable there. New unsubscribe-all actions apply within that brand; old workspace-scoped links retain their original scope. Workspace opt-outs and hard-bounce/complaint protections still apply.
- Archived brands retain history and usable unsubscribe/preference pages, but cannot start new sends. Archive is not deletion. There is no unarchive endpoint in this implementation.
Compatibility and migration
Audience creation now deliberately requires brandId. Update integrations that previously sent only name/description. The schema migration stops if existing marketing records require assignment; it does not create a default brand or backfill contacts. This is an operator migration prerequisite, not a customer endpoint.Python and Go SDK equivalents
Existing CLI audience command
Create the brand through the dashboard or API first. The CLI audience-create command forwards a JSON body, so include brandId in that body; there is no automatic assignment.Expected result
Every new audience belongs to an explicit brand, shared profile edits stay within it, and each membership retains independent consent.
Related guides
StackShift Mail overview
Mail APIs and workflows: isolated simulation, explicit brands, consent-aware campaigns, engagement, domain health, migration, spending, inbound delivery and diagnostics.
Events, webhooks, and timelines
List mail events, inspect per-message timelines, subscribe webhooks, rotate secrets, retry deliveries, and verify webhook signatures.
Subscriber consent and imports
Preview imports row by row, preserve consent evidence and use double opt-in before marketing delivery.
Streams, audiences, and campaigns
Separate transactional and broadcast traffic, retain consent evidence, and build private campaign drafts with unsubscribe protection.
Test environment
Exercise delivery, bounce, complaint and delay paths with isolated Mail data and no real email delivery.