Common types
Confirmations acknowledge that something completed. Order receipts, payment confirmations, booking acknowledgements and event RSVPs all fall here, and their job is to be findable months later.
Notifications report a change in state the recipient is waiting on. Shipping updates, delivery alerts, status changes and security warnings.
Account messages handle access and administration. Password resets, email verification, two-factor codes and subscription renewal notices.
The three differ in urgency rather than in kind. A verification code is useless after a few minutes, while a receipt retains value indefinitely, and that difference drives how each should be sent.
Key rules
No marketing content. A transactional message carries only information related to the action that triggered it, and adding promotional material changes what the message legally is. Kam, our co-founder, built that rule into the design layer itself. The transactional_plain design mode requires transaction details and a support path, and it rejects marketing copy outright.
That boundary is enforced by primary purpose rather than by intent. Under the CAN-SPAM Act, transactional and relationship messages are exempt from the opt-out and physical-address requirements, but a message whose primary purpose becomes commercial loses that exemption and needs both. The boundary cuts the other way too. We support marking legally required authentication and recovery steps in a flow as transactional, so a password reset still reaches a contact who unsubscribed from marketing, personalisation like the confirm URL intact.
Accurate headers and a non-deceptive subject line are required regardless of category. The exemption is partial, never total.
The SMS distinction
Consent works differently by channel, and this is the rule most often got wrong.
Transactional email generally does not require prior opt-in, because the recipient triggered it by taking an action with the sender.
SMS does. Under the Telephone Consumer Protection Act, codified at 47 USC 227, and the FCC's implementing rules at 47 CFR 64.1200, sending automated text messages requires prior express consent from the recipient, and the transactional nature of the message does not remove that requirement.
Treating an email address and a phone number as interchangeable contact fields is therefore a compliance error rather than a design shortcut. A system sending both needs separate consent state per channel.
Delivery requirements
Latency is a functional requirement for part of this class. A one-time passcode arriving in ninety seconds has failed even though it was delivered, so time to inbox belongs in the specification.
Send from a sending identity separate from marketing. Marketing generates complaints at rates transactional mail does not, and a shared sending domain means a campaign can degrade the reputation carrying password resets.
Decide the failure behaviour deliberately. A message that fails and silently retries a day later is frequently worse than one that fails visibly, because a password reset arriving 26 hours later is a support ticket rather than a delivery.
Include a support path. For anything concerning money or account access, somewhere to reply is the difference between a question and a dispute.
One recipient, no campaign machinery
A transactional message is a single-recipient send triggered by something a person just did, and the interface should reflect that. Ours queues one message through a single POST to /v1/my/messages, with delivery handled by the normal background sending path, and the agent-facing equivalent sends to one recipient immediately with no campaign, no audience and no approval step.
That last part is the design decision worth noticing. Campaign sending has an approval gate because a mistake reaches thousands of people. A transactional send does not, because the trigger already happened and the recipient is waiting, and putting a human in that loop would break the thing.
Content ownership sits with the application rather than the platform, which is the right default for this class of mail. Customers use the transactional path for signup and password reset messages where their own system decides what the message says, and the platform's job is delivery and status rather than composition.
The distinction from campaigns is not cosmetic. Retry semantics differ, status expectations differ, and failure means something different: a failed campaign send is a marketing problem, while a failed password reset is a person locked out of an account.
Getting a transactional message right by hand, the rules above, the idempotency, the one-recipient discipline, is exactly the kind of careful, repetitive work an AI agent should be doing instead of a person. That is the shift we built Nitrosend for: describe the receipt, the reset link or the reminder inside an agent like Claude or ChatGPT, and it sends the message correctly every time, without anyone re-checking the rules by hand.
Idempotency matters more here than anywhere else for the same reason. A retried campaign send is embarrassing, but a duplicated password reset issues a second live credential, which is why the same key on a retry has to produce the same result rather than a second send.