Transactional email
A message sent to one person because of something they did, and the rules that follow from that
A transactional email is sent to one person as a direct result of something that person did or something that happened to their account: a receipt, a password reset, an order confirmation, a shipping notice, a security alert.
The defining property is not the content. It is that the recipient is expecting it, because they caused it.
Why the distinction matters
- Consent works differently. A transactional message does not need marketing consent, because it is part of a transaction the person entered into. That exemption is narrow: attach a promotion to a receipt and the message is marketing with a receipt on it.
- An unsubscribe link is not required and is usually wrong. Nobody should be able to opt out of their own password reset.
- Timing matters more. Nobody minds a newsletter arriving an hour late. A password reset an hour late is a support ticket.
In Sendly
Transactional sends go through the REST API and are the path the compat endpoints translate. They draw on the same allowance as everything else: Sendly meters emails, not products, so transactional, campaign, workflow and inbound mail all count against one number.
They are still subject to your suppression list. A hard bounce means the address does not exist, and a receipt to a non-existent address helps nobody.
See Transactional emails and the send API, and use an idempotency key so a retry cannot duplicate one.