Separate account and transaction messages from marketing, apply the primary-purpose test, and send through a published Brew automation.
Transactional emails provide information about a transaction or relationship: a receipt, requested password reset, shipping update, or account-security notice. Their purpose is different from a campaign asking someone to buy or return.
The distinction depends on the message. Calling an email "transactional" in a sending tool does not decide its legal status.
The FTC's CAN-SPAM guidance describes narrow categories of transactional and relationship messages. For mixed commercial and transactional content, it considers what a reasonable recipient would understand from the subject and where the transactional information appears.
A promotional subject can make a mixed message commercial. A brief promotional footer does not automatically do so: the FTC gives an example of an account statement that remains primarily transactional. The rule and the actual message matter.
Keep essential information prominent. If a promotion distracts from a receipt or security notice, a separate marketing email is usually the clearer editorial choice. This is US guidance; review the requirements applicable to your recipients and business. Sources reviewed September 28, 2026.
| Message | Usual purpose | What to review |
|---|---|---|
| Order receipt or refund notice | Transactional | Accurate order information and an appropriate recipient |
| Requested password reset | Account security | A genuine request, a valid link, and no distracting offer |
| Shipping update | Transactional | Information about the existing order |
| Abandoned cart reminder | Marketing | Permission, current cart state, and unsubscribe behavior |
| Trial-expiry upgrade pitch | Marketing | The actual offer and whether the recipient is still eligible |
An account-status notice and an upgrade pitch can concern the same trial and serve different purposes. Review what the email asks the reader to do.
Gmail's guidelines distinguish one-click unsubscribe requirements for marketing and subscribed traffic from transactional messages. Authentication and reputation still matter to both.
Yahoo recommends separating bulk marketing from transactional traffic by IP and, where appropriate, domain. Follow your provider's setup rather than assuming that a new subdomain alone creates an independent reputation.
For marketing, RFC 8058 defines the one-click header mechanism. A footer link and a header-based unsubscribe have different roles. Test the behavior on the received message.
Brew uses a published automation and its trigger for this workflow. Configure a verified sending domain with the appropriate sending purpose, declare the trigger payload, and create a send-email step using that domain. The domain setting controls Brew's sending behavior; it does not make promotional content legally transactional.
After testing and publishing the automation, your backend fires the trigger. This example assumes the trigger declares order_id and ship_date:
curl --fail-with-body "https://brew.new/api/v1/automations/triggers/${BREW_ORDER_TRIGGER_ID}/fire" -H "Authorization: Bearer ${BREW_API_KEY}" -H "Content-Type: application/json" -H "Idempotency-Key: order-1234-shipped" -d '{"payload":{"email":"ada@example.com","order_id":"1234","ship_date":"Tuesday"}}'Use the actual trigger identifier and a stable idempotency key for the event. The email can read a declared payload field with syntax such as {{ trigger.order_id }}. Check the merge-tag documentation and test missing values.
Inspect the run and the received email. Test retry behavior and confirm that marketing unsubscribes are handled according to the sending purpose. Other protections, including delivery suppressions, still matter; a transactional setting is not a promise to deliver to every address.
The automation guide covers publication and state checks. If an assistant composes the template, the same sending review applies.
