Transactional Email Operations

Transactional email is for messages a person needs because of an action, request, or account state: password resets, receipts, login codes, account notices, and order confirmations.

Do not use transactional sends for newsletters, product updates, lifecycle campaigns, or winback messages. Use broadcasts, sequences, workflows, and consent-aware marketing paths for those.

What Counts As Transactional

Good transactional candidates:

Password reset and magic login links.
Email verification.
Receipts and invoices.
Order confirmations and shipping updates.
Security alerts.
Required account or policy notices.

Marketing candidates:

Product updates.
Promotional offers.
Educational sequences.
Re-engagement campaigns.
Newsletters.

Read Marketing vs Transactional when the boundary is unclear.

Before You Send

Complete these steps before production traffic:

Set up sender authentication in Bento.
Verify the from address is an author in your account.
Store API keys server-side.
Add rate limits to user-triggered actions such as password resets, login links, invites, and form submissions.
Send test emails to real inboxes and check rendering.
Confirm your app cannot send duplicate emails on retries.

Send Paths

Use one of these paths:

Path	Best for	Docs
SDK transactional method	Most app integrations.	SDKs
Emails API	Direct HTTP integrations.	Emails API
CLI	Scripts and operational sends.	Bento CLI
Workflow transactional email	Confirmation emails and product flows inside Bento.	Workflows

The Emails API queues requests quickly, then sends them through Bento's priority pipeline.

Templates And Personalization

Keep transactional templates stable and boring in the best way:

Use clear subjects.
Include both the reason for the email and the action the user requested.
Keep links on your authenticated domain where possible.
Use minimal personalization.
Avoid user-controlled HTML in names, company fields, or custom fields.

User-controlled personalization can become an injection vector. For security-sensitive emails, avoid dynamic content unless you sanitize it in your own app first.

Unsubscribes And Suppressions

Transactional messages can be sent even when a subscriber has unsubscribed from marketing if the email is truly required.

Rules of thumb:

Use transactional sends only for necessary account or purchase communication.
Do not use transactional flags to bypass marketing consent.
Respect hard bounces, complaints, and blocked addresses.
Do not delete unsubscribers just to recreate them later.

For broader contact rules, read Contacts And Consent.

Status And Bounces

When a transactional email does not arrive:

Check the recipient profile activity.
Confirm the sender domain is authenticated.
Check bounces and suppressions.
Search for content or link warnings.
Check whether your app sent duplicate or malformed requests.

Use Bounces, Sending Limits, and Troubleshooting for deeper diagnosis.

Unsupported Patterns

Avoid these patterns:

File attachments through the Emails API. Link to files instead.
URL shorteners.
Sending from unapproved or unauthenticated addresses.
Client-side API calls with secret keys.
Large fan-out sends from user-facing requests.
Reusing transactional sends for promotional campaigns.

Abuse Controls

Protect every app endpoint that can trigger an email:

Add per-user and per-IP rate limits.
Add CAPTCHA, bot checks, or honeypots to public forms.
Queue sends so traffic spikes do not create email spikes.
Do not include attacker-controlled values in the subject.
Log request source, user ID, and message type.

Launch Checklist

Emails API or SDK send works in staging.
Sender authentication is valid.
from address is an author.
User-facing trigger is rate limited.
Retries cannot create duplicate emails.
Bounces and complaints have an owner.
Support knows where to inspect a failed transactional send.