Order confirmations, refunds, payouts, approvals, support updates, and safety outcomes should come from the authoritative server workflow—not from somebody merely visiting a page.
FOUNDER QA · TRANSACTIONAL EMAIL
Email should confirm real ClaraWide events—not invent them.
This provider-neutral foundation defines the transactional emails ClaraWide needs, what triggers them, which messages are essential versus optional, and how production delivery should eventually work. Nothing on this page sends real email yet.
EVENT / TEMPLATE CATALOG
What ClaraWide may send
DELIVERY QUEUE
Browser-local email events
Preview queued does not mean delivered. QA reviewed only means the prototype content was inspected.
Select a template or queued email to preview it.
Each event needs a stable delivery key so retries cannot create duplicate email. Temporary failures retry with backoff; permanent failures move to review/suppression.
Verification, magic-link, and recovery tokens must be single-purpose, short-lived, rate-limited, safely stored, and invalid after use or replacement.
Production must process hard bounces, complaints, blocks, and suppressions instead of retrying known-bad addresses forever.
Essential account/order/security/support messages stay distinct from optional message/review/social alerts and future newsletters/promotions.
Subjects and preview text should avoid exposing sensitive message, safety, risk, or dispute information that does not need to appear on a lock screen.