Do I need a separate service for transactional email?
No. Broadcast sends both, and the difference that matters is unsubscribe behavior.
The distinction
Marketing email (broadcasts and sequences) respects unsubscribe status. Someone who opted out does not receive it.
Transactional email deliberately bypasses unsubscribe status, because a password reset or an order receipt has to arrive whether or not the recipient wants your newsletter. The transactional documentation explains exactly what this does and does not override.
That bypass is also why transactional sending should be reserved for genuinely transactional messages. Using it for promotional content is how sending reputations get damaged.
Sending one
Transactional email goes out through the API rather than the campaign composer. The Transactional Email API covers the endpoint, and you can send a test from the interface before wiring up code.
Worth setting up alongside it
- A separate email server for transactional traffic, so a marketing send that hits a rate limit cannot delay a password reset. Channels covers managing more than one email server.
- Templates with Liquid variables, so the message body lives in Broadcast rather than in your application code.
- Outgoing webhooks if your app needs to know whether the message was delivered.
Wondering whether a specific message counts as transactional? Ask us.
